Is it possible to send "100 Continue" HTTP status code, and then later some other status code after processing entire request using Java Servlet API (HttpServletResponse)?
I can't find any definitive "No" answer, although API doesn't seem to support it.
I assume you mean "100 Continue".
The answer is: no, you can't (at least not the way it's intended, as provisional response). In general, the servlet engine will do it automatically, when the request requires it. Of course this makes it impossibe for the servlet to prevent sending the 100 status -- this issue is a known problem in the Servlet API, and has been known for what feels like eons now.
I know that Jetty will wait until getReader() or getInputStream() is called before it sends a 100. I think this is the behavior you are looking for. I don't know what Tomcat does.
Did you mean to ask How do I send a status code before the complete request is received, to interrupt an in-progress request due to a missing header field? It seems that's not possible with standard servlets.
What server are you using?
Some server's servlet extensions may allow this, e.g. Tomcat's Comet servlet might send EventType.BEGIN once the headers are available to process, which may allow you to interrupt a PUT that doesn't have the correct authentication.
Alternatively your server might have a plugin to reject requests based on headers.
Do you mean status code 100 ?
The API does support sending SC_CONTINUE.
Related
I am consuming a REST webservice, which is hosted on a remote server.
Now, the web service's POST, PUT and DELETE methods are blocked by the server's firewall. So I have only GET method left.
Is there a way I can use GET to work as POST or PUT or DELETE ?
I am using jersey api for consuming the services.
https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962
Yes. In other words, any HTTP request message is allowed to contain
a message body, and thus must parse messages with that in mind.
Server semantics for GET, however, are restricted such that a body,
if any, has no semantic meaning to the request. The requirements
on parsing are separate from the requirements on method semantics.
So, yes, you can send a body with GET, and no, it is never useful
to do so.
This is part of the layered design of HTTP/1.1 that will become
clear again once the spec is partitioned (work in progress).
....Roy
This means you can send a message body with your GET request but it would have no meaning. If your server firewall doesn't allow you to receive requests other than GET you should try to talk to your admin, change the server and if that's not possible due to company reasons you should escalate it via your manager.
edit: as Kayaman said it's not your job to do that. if you are not given the right infrastructure, you just can't work. if you are not given a computer nobody would expect you to be able to code.
In a Servlet what happens If the developer messes up with the headers.
Let's say client's HTTP version is 1.0 and in
the request is not present a connection header,
inside my servlet I can do the following:
resp.setHeader("connection","keep-alive");
I also can set content-length to a specific value
and then send way less or more data
than the specified value
I'm sure exsist other situations that can cause similar "problems" as well.
How are these problems handled?
In general, it is unpredictable. In most cases the relevant specifications don't say what should happen. And even when they do, there is no guarantee that the respective server-side (or client-side) will do what is specified ... or advised by the spec.
Let's say client's HTTP version is 1.0 and in the request is not present a connection header, inside my servlet I can resp.setHeader("connection","keep-alive");
The client probably should just ignore the connection response.
I also can set content-length to a specific value and then send way less or more data than the specified value.
I recall seeing in the Servlet spec that the server-side framework is supposed to close the response automatically if the webapp writes more bytes than the content-length. But if the webapp writes less, there is nothing that the server-side can do. The client simply has to cope with this. The situation is indistinguishable from the case where the server crashes.
How are these problems handled?
It is generally implementation dependent.
This all handles on client side, and depends on browser, and vary from one to another.
But I suppose that described situation with connection header will be hadled very simple:
the browser with HTTP 1/.0 only is not supporting keep-alive connections, so will simply close connection afer each request.
I have an application using Apache HttpClient 3.1.
I want to know how much data the application sends and receives and I want to measure this "per thread" (i.e. I want to know how much data a specific thread sent and received).
I currently simply count the number of bytes received in the content, but that's not what I need. Traffic sent should include the request headers and traffic received should include the response headers... (many requests just return "OK" or an empty body so I think the headers make up for more than 50% of total traffic).
I would very much like a solution for HttpClient 3.1 since the upgrade to 4.x does not seem trivial and I'm otherwise happy with 3.1.
I've done some searching and found connection.getMetrics() which seems to exist only for 4.x :(
If it really has to be 4.x, then how would I do it, I never explicitly handle connections, I currently simply call client.executeMethod(method); and then method.getResponseBodyAsStream()...
Thanks in advance for any help :)
How can I make a java-based application server reply with an empty-valued response header, like this?
content-length:\r\n
Unfortunately when I call
response.setHeader("Content-Length", len)
where len is either an empty string or null, the response will not include the header.
I've checked the HttpServletResponse and HttpServletResponseWrapper javadocs but couldn't figure out what could be overriden to provide my custom behaviour.
Background
I'm building a testing application that is supposed to emulate badly-behaved HTTP server scenarios. The application is supposed to reply to requests with preset pages and HTTP headers, including malformed ones like the above case.
The application is written in grails.
I'm building a testing application that is supposed to emulate badly-behaved HTTP server scenarios.
In such a case, attempting to get a well-behaving server to mimic such behavior is a bad idea. If you need to mimic a bad server, or a particular set of scenarios you wish to test, then you may do one of the following:
write a custom application that listens on a particular port (using the ServerSocket class) that will respond with malformed HTTP headers. Using HTTP libraries may not help, for libraries may have code to detect erroneous conditions and correct them automatically.
use a HTTP proxy that is capable of intercepting responses and allows for modifications of these responses. You will find several if you Google for "http debugging proxy", but if you haven't heard of any, I would suggest looking at Fiddler, WebScarab or Burp.
You can try a tool like SoapUI or Fiddler with it's Firefox extension. I havent tried setting a malformed header with them but I wouldn't be suprised if you could.
Something not clear for me: your application is written in Grails, but you are discussing of javadocs... Well, I suppose you try to create a bad server in JAVA...
As you said, answering with "Content-Length:\r\n" is not legal for HTTP. You must put an integer value or discard the header. I think setHeader() helps you to avoid to produce an illegal HTTP message.
You can workaround this way creating manually the headers (you can write directly to the socket without using the setHeader blocks).
Other solution is to create a filter (in addition of your servlet) with your own implementation of HttpServletResponse. You will pass this implementation to the servlet.
This problem relates to the Restlet framework and Java
When a client wants to discover the resources available on a server - they must send an HTTP request with OPTIONS as the request type. This is fine I guess for non human readable clients - i.e. in code rather than a browser.
The problem I see here is - browsers (human readable) using GET, will NOT be able to quickly discover the resources available to them and find out some extra help documentation etc - because they do not use OPTIONS as a request type.
Is there a way to make a browser send an OPTIONS/GET request so the server can fire back formatted XML to the client (as this is what happens in Restlet - i.e. the server response is to send all information back as XML), and display this in the browser?
Or have I got my thinking all wrong - i.e. the point of OPTIONS is that is meant to be used inside a client's code and not meant to be read via a browser.
Use the TunnelService (which by default is already enabled) and simply add the method=OPTIONS query parameter to your URL.
(The Restlet FAQ Q19 is a similar question.)
I think OPTIONS is not designed to be 'user-visible'.
How would you dispatch an OPTIONS request from the browser ? (note that the form element only allows GET and POST).
You could send it using XmlHttpRequest and then get back XML in your Javascript callback and render it appropriately. But I'm not convinced this is something that your user should really know about!