Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is it possible to set the response status code in Apache using JAVA

 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All


Is it possible to set the response status code ,like 212,299,etc.............................
in Apache,

OS :windows
Platform:java


Thanks
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64688
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You mean in a response returned from a servlet? Yes. Check the API for HttpServletResponse.
 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for quick reply
but I tried to do it by setting in my code

response.setStatus(212);

it returns 500 ,but works fine when I am sending a response like 200 to 207 or 300 to 307 or 400 to 426 which are predefine status codes in Apache.
[ November 07, 2008: Message edited by: Talitha Bell ]
 
Amit Ghorpade
Bartender
Posts: 2854
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


What is the 212 status code for? There is no such code defined in the HTTP protocol.The browser is not able to interpret it and hence its assuming it to be 500(internal server error). Here is a list of the available status codes.

Hope this helps
 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for reply

When I set this response status in my code and run it on jboss its work fine.

Problem is that i want to set my response(like 212,....etc ) in my code for specific task by getting it .
here the link want I want to do is http://www.coderanch.com/t/421464/JBoss/Configure-apache-jboss-Response

Is there any solution..
 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would suggest that you stick to the response codes that are part of HttpServletResponse. That's an indication of what a servlet container should be able to handle.

I'm not sure if the servlet spec actually specifies what should happen for other status codes, but apparently there may be problems, as you've found out.
 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no such code defined in the HTTP protocol


I know that I am asking you foolish question but..............

This response code only for Apache or for any other web server.Can you explain it.
 
Amit Ghorpade
Bartender
Posts: 2854
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Talitha Bell:


This response code only for Apache or for any other web server.Can you explain it.


They are the HTTP protocol status codes, not specific to any server.
In fact all HTTP servers are bound to follow those codes as specified by the protocol standard.


I know that I am asking you foolish question but..............

There are no foolish questions. A question is a always a question, whatever it is

Can you tell us why you want a custom status code? Maybe your problem has a better solution.
 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This response code only for Apache or for any other web server.

The response codes are defined by the HTTP specification. It is then up to the HTTP servers to return them under the correct circumstances. This diagram goes into a lot of detail about which status should be returned under which circumstances.
[ November 07, 2008: Message edited by: Ulf Dittmer ]
 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you tell us why you want a custom status code


My problem is same as I post the link above,we are trying to do is we send the custom response like(212 or etc rather than HTTP STATUS RESPONSE CODES),because HTTP STATUS RESPONSE CODES have some meaning(way of communication between client and server) ,so we are not want to take a chance to do with these codes (if any exception or something generate)and after getting those response which have some operations ,and also have some operation if we get predefine HTTP STATUS RESPONSE CODES web page.

But we easily find it on JBoss but not on Apache+jboss
 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This sounds like you're trying to break HTTP, one of the most ubiquitous communication protocols in existence - don't do that, it is asking for trouble. You can return custom codes or messages as part of the response body (or as response header, if the client supports that).
 
Talitha Bell
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ulf Dittmer for reply..............
messages as part of the response body (or as response header, if the client supports that)


I will try to do that but Could you please explain me why it give me problem when it work with jboss not for Apache.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There probably isn't a specific reason.

Webservers, and applications servers are, for the most part, built around the specs for the technologies they intend to support (HTTP, Servlet, JSP, etc..).
As long as they can be tested against those specs and perform as expected they are considered to be working correctly (spec compliant).

How they handle something that falls outside the spec or how they handle things that, in the spec, that aren't clear or could be interpreted in several ways is going to be very much vendor specific. Any time we, the application developer, code our apps around non-spec compliant features we run the risk that our applications will be non-portable; not only from one server to another but even from one version of a particular server to the next.

I would follow Ulf's advice and rethink your approach.
If you can come up with a solution that adheres to the HTTP specification, you stand a much better chance that your app will be portable and robust enough to handle server upgrades in the future.
[ November 07, 2008: Message edited by: Ben Souther ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic