Ok so I've been reading up on HTTP and found this page. This is an example HTTP request that was posted there:
GET /http.html Http1.1
Host: www.http.header.free.fr
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
Accept-Language: Fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Connection: Keep-Alive
I tried it in telnet and it worked. But everywhere else I see this kind of request line
GET /http.html HTTP/1.1
The important different is that HTTP is all caps and the / character.
Are they both correct? They both seem to work on the sites I've tested it on. I've skimmed the RFC of HTTP but didn't find anything of use. Has anyone else seen this kind of request header? Is it officially supported?
Refering to the HTTP protocol, it must be in HTTP/1.1 or HTTP/1.0 (older one). Now it depend how the http server was developed. It may accept it but you should not rely on it.
EDIT:
your answer is here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3 :
HTTP-Version = "HTTP" "/" 1*DIGIT
"." 1*DIGIT
And now the protocol is 1.1 so you should use: GET /http.html HTTP/1.1
According to RFC2145 (page 3),
RFC791 [4] defines the "robustness principle" in section 3.2:
an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.
This principle applies to HTTP, as well. It is the fundamental basis for interpreting any part of the HTTP specification that might still be ambiguous. In particular, implementations of HTTP SHOULD NOT reject messages or generate errors unnecessarily.
And in particular:
It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header that it does not understand MUST ignore that header.
So the server is ignoring the version number in the case that it's "Http1.1" (which is not valid) and presumably it's interpreting the message as a HTTP/1.0 message (or maybe even HTTP/0.9!). Of course, you should not rely on this behaviour!
It should be
GET /http.html HTTP/1.1
Related
How should an HTTP Agent make decisions about using cached response when a request has the same path but different headers?
Take for example this HTTP request/response:
GET /resource HTTP/1.1
Host: example.org
X-Filter: foo=bar
HTTP/1.1 200 OK
Cache-Control: max-age=3600
Content-Type: application/json
Content-Length: 13
{"foo":"bar"}
Should the agent consider the response valid for a second request with a different X-Filter header? For example:
GET /resource HTTP/1.1
Host: example.org
X-Filter: foo=baz
then within an hour from the first request, should the agent request a fresh response since the request header differs, or should use the cached response from the first request, ignoring the header?
I'm asking this because I noticed that Google Chrome makes a new request, Microsoft Edge instead use the cached response.
You should use the cached version unless changed header appears in the list provided by the (optional) Vary response header.
For example, a response that contains
Vary: accept-encoding, accept-language
indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language fields (or lack thereof) as
determining factors while choosing the content for this response.
I'm receiving invalid characters on try to receiving JSON by http protocol in C.
When I send
GET /<query> http/1.1\r\nHost:<host>\r\n\r\n
then the result displays as follow:
HTTP/1.0 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: false
X-Content-Type-Options: nosniff
Date: Sun, 07 Dec 2014 13:14:29 GMT
Content-Length: 11410
�
I don't know why I don't receiving JSON? However, in browser's address bar I type the same query & I received the json as well.
[UPDATE # 1]
I found it useful to work on built-in library, as the error is related to network byte compressions so I used Qt's library QNetworkManager specifically to done this job.
Please use a HTTP library or make yourself comfortable with the HTTP protocol and implement it properly.
Content-Encoding: gzip
At least this line means trouble for your simple parsing. But interestingly, based on your request the server should not sent this line if a non-compressed version is available. This means not only your code is buggy, but that the server might be buggy too (it actually assume that you understand any compressions because you did not say different).
GET / http/1.1\r\nHost:\r\n\r\n
And your request is wrong too. It must be HTTP/1.1 instead of http/1.1. And it must contain a proper host header.
Qt's QNetworkManager is best for this purpose, as it do all the intricate stuff itself & provide elegant interface to user.
I was comparing headers of same HTTP Post request for Firefox and Internet Explorer and I see that for IE.
I was wondering:
What does Accept: */* mean under Client section of Request Headers?
The accept: header defines the content type the client accepts, or expects to be returned by the server. Depending on the situation this can be text/css, text/html, image/png, .. etc. - just some mime type.
The * character is considered the wildcard. accept: */* simply means that any data of whatever mimetype is accepted and the server may choose what to return to the requesting client.
It's answered in the specification. See http://greenbytes.de/tech/webdav/rfc2616.html#header.accept and http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-21.html#header.accept
I've set up a bit of a test site.. I'm trying to implement an HTML5 video to play on a site I'm developing and I want to use jplayer so that it falls back to an swf file if html5 video is not supported.
http://dev.johnhunt.com.au/ is what I have so far. It works fine if I provide http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v for the video, however if I host it on my own server it simply never starts playing.
The mime type is definitely correct, video/m4v. Charles proxy says:
Client closed connection before receiving entire response
Infact, here's the entire request:
GET /Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host dev.johnhunt.com.au
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=120066461.1007786402.1349773481.1349773481.1349786970.2; __utmb=120066461.1.10.1349786970; __utmc=120066461; __utmz=120066461.1349773481.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Range bytes=0-
And response:
Some binary data (maybe 3 or 4kbytes long)
Which looks ok. I assume the 'client' is my chrome browser.. why is it giving up? How can I fix this? It's driving me mad as I can't find anything on google :(
When I use the m4v file on jplayer.org this is the request:
GET /video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host www.jplayer.org
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=24821473.325705124.1349773077.1349773077.1349773077.1; __utmc=24821473; __utmz=24821473.1349773077.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Range bytes=0-
Response:
Lots of binary data (very long.. working)
Cheers,
John.
I've found that when the Chrome browser sends a "Range: bytes=0-" request, you should NOT respond with a "206 Partial Content" response. To get Chrome to handle the data properly, you need to send back a "200 OK" header.
I don't know if this is correct according to the specs but it gets Chrome to work and does not appear to break other browsers.
Having just run into this with Chrome, it seems that you need to ensure that the Content-Range header is set by your server in the response.
From http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html:
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
. The first 500 bytes:
bytes 0-499/1234
. The second 500 bytes:
bytes 500-999/1234
. All except for the first 500 bytes:
bytes 500-1233/1234
. The last 500 bytes:
bytes 734-1233/1234
Might be a problem on your apache... presumably you are using apache given the tag.
Have you added the mime types to apache?
e.g.
AddType video/mp4 mp4
AddType video/mp4 m4v
Also check that gzip is turned off for for the media... it is already compressed... and don't gzip Jplayer.swf.
Can you post your apache config? Are you using any streaming modules such as this?
Cheers
Robin
EDIT
o and also you might want to accept-ranges bytes in apache. If you look closesly at the two links you are serving a 200 and they are serving a 206 partial data.
I've never seen this before, I've always known there was either GET or POST. And I can't find any good documentation.
GET send variables via the URL.
POST send it via the file body?
What does HEAD do?
It doesn't get used often, am I correct?
W3schools.com doesn't even mention it.
HTML’s method attribute only allows GET and POST.
The HEAD method is used to send the request and retrieve just the HTTP header as response. For example, a client application can issue a HEAD request to check the size of a file (from HTTP headers) without downloading it. As Arjan points out, it's not even valid in HTML forms.
HTTP method HEAD sends the response's headers but without a body; it's often useful, as the URL I've given explains, though hardly ever in a "form" HTML tag.
The only thing I can imagine is that the server may actually have been set up to validate the request method, to discover submissions by robots that for HEAD might actually use a different method than a browser does. (And thus reject those submissions.)
A response to a HEAD request does not imply nothing is shown to the user: even a response to HEAD can very well redirect to another page. However, like Gumbo noted: it's not valid for the method in a HTML form, so this would require a lot of testing in each possible browser...
For a moment I wondered if HEAD in a form is somehow used to avoid accidental multiple submissions. But I assume the only useful response would be a 301 Redirect, but that could also be used with GET or POST, so I don't see how HEAD would solve any issues.
A quick test in the current versions of both Safari and Firefox on a Mac shows that actually a GET is invoked. Of course, assuming this is undocumented behavior, one should not rely on that. Maybe for some time, spam robots were in fact fooled into using HEAD (which would then be rejected on the server), or might be fooled into skipping this form if they would only support GET and POST. But even the dumbest robot programmer (aren't they all dumb for not understanding their work is evil?) would soon have learned that a browser converts this into GET.
(Do you have an example of a website that uses this? Are you sure there's no JavaScript that changes this, or does something else? Can anyone test what Internet Explorer sends?)
HEAD Method
The HEAD method is functionally like GET, except that the server replies with a response line and headers, but no entity-body. Following is a simple example which makes use of HEAD method to fetch header information about hello.htm:
HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Following will be a server response against the above GET request:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
You can notice that here server does not send any data after header.
-Obtained from tutorialspoint.com