Question

I am integrating with a system that is sending HTTP-GET requests to our application. Using Jetty, it took a few minutes to slap something together.

I tested it with curl (with the necessary escapes in the request) and all was rosy. I got the response back as requested:

$ curl http://localhost:9100?field1=value1\&field2=value2\&field3=value3

A TCP dump on the machine, shows the request coming through as:

GET /?field1=value1&field2=value2&field3=value3 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3    libidn/1.18 libssh2/1.2.2
Host: xxx.xxx.xxx.xxx:9100
Accept: */*

However, life is never that simple. When I deployed this so that we can actually start integrating with the real system, the handler in my code did not even get called. Jetty responded with “HTTP/1.1 400 Bad Request” immediately. A TCP dump revealed the following:

GET ?field1=value1&field2=value2&field3=value3 HTTP/1.1

That’s it… no header information, just the above.

My question now is whether the request above is actually valid. Is the slash required? Is any of the header entries compulsory?

Any ideas? Does this mean I have to redesign the wheel to get this working?

---

EDIT:

I tried using telnet to connect. It seems like the / is indeed required after the GET request for some webservers. However, it seems it is handled differently between them. Jetty complains, the webserver that google runs on complains… however Apache is an example of one that is fine with it. None of the header information seems to be required.

Answer 1

RFC 2616 provides all the sundry details:

3.2.2

If the abs_path is not present in the URL, it MUST be given as “/”
when used as a Request-URI for a resource (section 5.1.2).

14.23

A client MUST include a Host header field in all HTTP/1.1 request
messages .