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.
Related
For an assignment, I have written a server that services HTML files and I am supposed to use my web browser as a test client. I am also told that if there is a request for a file that doesn't exist i should send the following
HTTP/1.1 404 Not Found\r\n\r\n and if anything else goes wrong
HTTP/1.1 500 Internal Server Error\r\n\r\n"
I have run tests that should cause those to be sent, but nothing occurs in my browser window? Should I be getting any visual feedback from sending such a request?
In an HTML response there should only be one CRLF (carriage return and line feed) after each line. So you can first remove the extra \r\n.
Also on the second line you can send an HTML response back to the client saying what the error was if you want to show an error. This is normally what a typical web server does where it has its default error page if one is not defined. If you are not sending any HTTP headers, then you can insert the HTML body you want to send back such as <h1> No page found</h1> as the second line.
To include an "entity" in an http response
HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 10
01234576789
each line is ended by CRLF. Be sure to count the Content-Length correctly.
I see that this is a learning exercise, and understand that you may have been told to implement the server this way. But bearing that in mind ...
This is the wrong way to implement a web server / service. The right way is to find an existing implementation and build your service on top of that.
You could use a Java EE web container; i.e. something that implements the Servlets spec.
You could use a non-servlet framework (like Grizzly).
You could build on top of a server-side HTTP protocol stack; e.g. using Apache the HttpComponent library.
Building a web server from the ground up is a lot of work if you are going to do it properly. And the chances that you won't do it properly; i.e. you won't implement your service according how the HTTP spec says a server should behave. You will leave things out, do things the wrong way, etc.
Please don't do it. There are already too many broken (i.e. non-compliant) web servers out there. We don't need more.
And if you DO decide to implement HTTP from the ground up, then you (YOU) need to thoroughly read and understand the HTTP spec. And you (YOU) need to do your own basic research on how browsers implement the client side of the spec ... and what you therefore need to do on the server side to make browsers behave "normally".
I currently have an TCP Java socket communication implementation in which I have a server that is listening to a port (let's say port 5478). Then I need an Android client to remotely connect to the Java server and send a SQL query, than will then be executed on the server side database and then I want to send a list of results back to the Android client (already implemented with a custom Java class named Result that implements Serializable). I do this by sending an ArrayList of Result to the Android client. The Java server is always listening to the port and supports multiple clients trough multiple Threads. How can I migrate this implementation to a more secure platform and what is the best way to do it? I don't need to respect HTTP protocol to afford this communication. Is Tomcat the best solution?
Thanks
I would use Servlet3.0 as part of tomcat.
Then from android you just have to send http requests to the server using a URL and the servlet can database them. You can also serialize the data as well if you need to.
I hope that answers your question.
~ Dan
//EDIT:
Once you have set up eclipse and tomcat, you can start writing servlets. First - you have to configure the server to use servlets for certain addresses, for example localhost:8080/myServlet - that means that anything you send to local host triggers the servlet. The code for your first servelet looks like this:
public class ExampServlet extends HttpServlet {
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
Your doPost method is what gets called when you perform a http post request on the address the servlet is listening on. Then, all you have to do it put some code in to read the request to get the data out of the message body. Basically you read your request object that gets passed in, and you write to your response object to send the response back to the client. There are plenty of guides out there. I followed something like this to get started:
http://www.coreservlets.com/Apache-Tomcat-Tutorial/tomcat-7-with-eclipse.html
Hope that helps :)
~ Dan
Tomcat is an Servlet container + webserver. If you plan to move to tomcat then you are implicitly moving to http. And yes, if you want a secure communication .. you can create a soap based webservice(apache axis) and host it on https.
I'm not sure how mutch additional security tomcat is able to provide for your application. Two tings come to mind:
Enforcing authentication and some access rules. This is not too hart to implement and heavily depends on the rule quality. However it may help f you use it. It's often replaced by own imlpementations. However, to get securty you need encryption i.e. https. Or it's possible to steel the session and gain the rights bound to it.
Request to file mapping. This in fact somewhat more complicated. You shouldn't code this on your own. It's more complicated than it looks at first sight.
However, one of the biggest security wholes ever is directly executing code you got from somewhere. For example SQL statements. Ok it's secure as long as your databse rights are set perfectly...
Developing a securly encrypted protocol is not simple either.
However, the major win on switching to tomcat (or whatever) might be scaleability for free. And I think implementing servlets is much simpler than programming against sockets. And there are many great to tools fo working with http(s) though ven it might be more complicated than yours, it's pretty simple to deal with.
Unfortunately I can't answer our question. I don't know what's the best solution is. But I think there's at least some potential for wins.
I'm a little unfamiliar both with the Servlet API and Apache Http Components.
I need to handle an incoming POST request with unknown data (although probably the result of a form submission) using HttpServlet.doPost() which I've implemented, and request the same posted information from another URL, effectively acting as a relay for the HTTP POST. I then need to convert the response to a String (it will be text/html) and process it further before returning it to the web browser that requested it from me.
Due to my unfamiliarity with these libraries, its not clear to me how to handle issues like the content-type of the posted data, and also avoiding any problems due to neglecting to release resources.
Can anyone provide any pointers on this?
You should start by having a look at HttpClient class from apache API.
It will handle both get and posts as needed and later you could feel its request with the data you receive in your own servlet.
I need to make an HTTP request to a resource that looks like "xy:index.html" in Java.
The HTTP implementation does not have to be sophisticated. I just need to be able to do this to avoid same-origin violations when running in development mode for a GWT app by forwarding HTTP requests on the server-side to the "xy" protocol.
Any clues about how I may be able to do this would be extremely appreciated. I feel like I'm a bit out of my league on this one ;)
I'm not sure if I understand the question properly but perhaps you can register a URL handler. This link has some info about how to do that. Perhaps you can register a custom handler for the xy: protocol and re-use the HTTP URL handlder for the real work.
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.