HTTP header 400 bad request response

1
votes

I'm trying to test writing correct HTTP headers to understand the syntax. Here I'm trying to PUT some text into httpbin.org/put and I expect the response body content to be the same.

PUT /HTTP/1.1
Host: httpbin.org
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/plain
Content-Length: 12 

Hello jerome

However I'm getting the following bad request 400 response:

HTTP/1.1 400 Bad Request
Server: nginx
Date: Tue, 01 Mar 2016 12:34:02 GMT
Content-Type: text/html
Content-Length: 166
Connection: close
Response:

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>

What syntactical errors have I done? NOTE: newlines are \r\n not \n in the request.

3
http
how are you making the request/ – Amit Kumar Ghosh
I'm using sockets in c. I want to break the abstraction most languages provide – XYZ Rose

3 Answers

1
votes

Apparently the correct syntax goes like this for PUT:

   PUT /put HTTP/1.1\r\n
   Content-Length: 11\r\n
   Content-Type: text/plain\r\n
   Host: httpbin.org\r\n\r\n
   hello lala\n

I believe I didn't say much on how I connected to httpbin.org; it was via sockets in C. So the connection was already established before sending the header + message.

0
votes

You miss the destination url following the PUT verb, the first line must be:

PUT http://httpbin.org/ HTTP/1.1

This will probably also fail, you need one of their handler urls so they know what to reply with:

PUT http://httpbin.org/put HTTP/1.1
0
votes

The general form of the first line, or Request Line, in an HTTP request is as follows:

<method> <path component of URL, or absolute URL> HTTP/<Version>\r\n

Where for your example, the method is PUT. Including an absolute URL (so, starting with http:// or https:// is only necessary when connecting to a proxy, because the proxy will then attempt to retrieve that URL, rather than attempt to serve a local resource (as found by the path component).

As presented, the only change you should have needed to make was ensuring there was a space between the / and HTTP/1.1. Otherwise, the path would be "/HTTP/1.1"... which would be a 404, if it weren't already a badly formed request. /HTTP/1.1 being interpreted as a path means the HTTP server that's parsing your request line doesn't find the protocol specifier (the HTTP/1.1 bit) before the terminating \r\n... and that's one example of how 400 response codes are born.

Hope that helped. Consult the HTTP 1.1 RFC (2616), section 5.1 for more information and the official definitions.