HTTP 1.0 vs HTTP 1.1 compression/decompression support.
I know that technically HTTP 1.0 supports compression/decompression (but it depends on browser as I understand), but a lot resources say that HTTP 1.1 has enhanced support and can't find reasonable answer to my question.
So the question is: Does HTTP 1.0 support compression and if yes under what conditions and what are those enhancements in HTTP 1.1?
Related
I just started studying network and by network I mean the fundamental concepts and topologies.
I learned that currently the up-to-date version of HTTP is 2.0 and, according to my research, it seems that HTTP 2.0 is quite universal in the web environment.
But while checking the request and response message in my Chrome browser's mode, I found out that quite a lot of the messages(actually almost every message) were using HTTP 1.1. I tried with well-known web pages like FB, Google etc. but they were all using HTTP 1.1.
My question is, if HTTP 2.o is truly in general use, why are my messages in HTTP 1.1?
And if in fact a lot of messages are sent in HTTP 1.1, why is HTTP 2.0 still not used as people say?
Edited
I tried this way.
Here is the screenshot
I'm trying to code an HTTP 1.0 (and only 1.0 for the moment) server in C++.
I've read the HTTP 1.0 specs here : https://www.w3.org/Protocols/HTTP/1.0/spec.html.
On section 3 "Protocol Parameters", subsection 3.1 "HTTP Version", i've found nothing when a client sent a different version from the server.
According to https://www.w3.org/DesignIssues/Protocolcomms.html, when version mismatch, we have two possibilities:
Version(server) = Version(client) + 1 : Should downgrade to the previous version (Impossible? My server handle only one specific version - may i have to handle HTTP 0.9?)
Version(server) > Version(client) + 1: An alert is given to the user (wich one? 4xx, 5xx?)
An official quote from the IETF RFC's should be appreciable, or at least an example with current most used web servers like Apache or Nginx.
You seem to be interpreting the last-mentioned document incorrectly. In your case, the issue is v(ME) < v(IT) (or v(ME) + 1 = v(IT)), and the document doesn't present a solution for that situation.
However, RFC 2616 (HTTP/1.1) states (in 19.6):
And we would expect HTTP/1.1 clients to:
recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.
So if you implement a fully compliant 1.0 server, the client should accept its responses.
RFC 7230 also has some pointers on how to deal with 1.1 clients.
I'm implementing a basic http client for communicating with a web service and am wondering if I should go with http 1.0 or 1.1.
The data section will consist of binary data and the remote server will always be controlled by me (running IIS7.5). The firewalls / proxies inbetween is nothing I'm controlling, ie. the packets must not be stopped if wrong http version is used.
I've been reading up about the difference between http 1.0 and 1.1 and it seems to me that http 1.0 supports everything I need.
Will I encounter problems if i choose http 1.0 over 1.1 or can I assume that everything will work just as good?
What makes me wonder is that if I connect via raw sockets to IIS7.5 and send a http 1.0 get request, the response is always http 1.1.
A firewall certainly will not block it and a router will route it.
I would suggest using HTTP 1.1. Chances are nothing will be affected if you use HTTP 1.0. However, you never know who else might use your HTTP client in the future and what horrible server implementation it will be used with.
You also need to ask yourself why you are implementing an HTTP client in the first place. Why not just use a standard library? I do not know what language you are using, but libcurl has bindings for many languages.
You can see more about libcurl here.
I don't think there's anything wrong using 1.0 as a client, most web servers are backward compatible.
If you're really have concerns, send 1.1 and only deal with stuff you want to handle, I don't think there's anything possibly go wrong choose either case.
Why does almost every example I can find (including this question from about a year ago) say that a 404 header should be HTTP/1.0 404 Not Found when we've really been using HTTP 1.1 for over a decade? Is there any reason not to send HTTP/1.1 404 Not Found instead?
(Not that it matters all that much... I'm mostly just curious.)
In PHP you should probably use:
header( $_SERVER['SERVER_PROTOCOL']." 404 Not Found", true );
or even better
header( $_ENV['SERVER_PROTOCOL']." 404 Not Found", true );
(if supported) and thus leave it to the web-server which protocol to use.
Actually, if you pass the status code as 3rd parameter, you can pass whatever you want in the 1st one, as long as it's not empty, and PHP will do the rest. See http://php.net/header
header("foobar", true, 404 );
Also: You can't request a certain protocol version from the client-side since the transaction is hop-to-hop based, and not end-to-end. The server and your browser may very well use HTTP/1.1, but if a proxy inbetween is using only HTTP/1.0, that's what you will see from your client.
The usage of HTTP version can be based on the following factors:
Your web server support for HTTP 1.0 or 1.1
The web browser's support for HTTP 1.0 or 1.1
Your preference as a web developer on which protocol version to use
Modern browsers can support both 1.0 and 1.1 well, and both the client and server will settle for the highest version both can support together. The key differences between the 2 protocol can be found: http://www8.org/w8-papers/5c-protocols/key/key.html
However there's no key differences in the usage of 404 Not Found. However do be consistent for your whole website. i.e. if you use HTTP/1.1, you use it throughout your website.
It does not matter all that much. The client is responsible for telling the server which version of HTTP it uses. Then, the server is supposed to answer with the same version. This does not always happen; I just got this response from a server:
$ telnet example.com 80
Trying 123.123.123.123...
Connected to example.com.
Escape character is '^]'.
GET /fork HTTP/1.0
HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 04 May 2010 22:30:36 GMT
Connection: close
I asked the server to use HTTP 1.0, but it went ahead and responded with HTTP 1.1.
I'd have thought that the response should be HTTP/1.0 404 Not Found if the request was a HTTP 1.0, and HTTP/1.1 404 Not Found if the request was HTTP 1.1.
In practice, it's going to be easier for servers to returned canned responses, and the HTTP 1.0 response will be understood by both 1.0 and 1.1 clients, so safest to return that. If you know the client understands 1.1 (e.g. because that's what it asked for), then the 1.1 response should work.
Arguably, play it safe and send the 1.0 response.
Looking at both the 1.1 and 1.0 RFCs, 404 is there in both - so it's probably for no other reason than for the server to communicate to the client that it's operating on http 1.1.
That said - if a server responds with 404 over Http 1.1, it implies that it could have returned 410 - Gone instead to indicate a resource that used to exist but no longer does. This status code is not part of 1.0, and therefore this information could be useful to a client (especially web crawlers).
EDIT
Sorry - this answer is probably answering the other way around! I reckon you can probably count on only a few hands the number of public web servers that will be bothering to remember all the resources that used to exist and which no longer do (no way I'd code that into my web server!) - so therefore it's probably best to respond with the 1.0 404 to indicate that 'it's just not there' rather than 'that's not here, but other stuff around the site might used to have been but no longer - in which case I could have sent you a 410'.
There's also the fact that you're allowing 1.0-only clients to work with your site.
That said - it's all a bit pedantic.
With modern versions of PHP you can also use the http_response_code function and sidestep the problem entirely!
I also like this method because it means that there's no risk of making typos in the response message.
I got this error when i used "avio_http_serve_files" witch is an http server It is given as example in ffmgeg (see ffpmeg git).
In order to start the server , the syntax is for example:
./avio_http_serve_files mymovie.mp4 http://192.168.1.42:10000
At client side:
vlc ou mpv ou...
vlc http://192.168.1.42:10000/mymovie.mp4
If the file mymovie.mp4 is not int the server 's current directory you have the error HTTP/1.0 404 Not Found.
You can neither use absolute directory.
Say one is to write an HTTP server/client, how important is it to support HTTP/1.0? Is it still used anywhere nowdays?
Edit: I'm less concerned with the usefullness/importance of HTTP/1.0, rather the amount of software that actually uses it for non-internal (unit testing being internal use, for example) purposes in the real world (browsers, robots, smartphones/stupidphones, etc...).
As of 2016, you would think that the prominence would decline even more since 1.1 was introduced in 1999 so this is about 17 years.
I checked 7,727,198 lines of logs to see what percent I get of HTTP/1.0 and HTTP/1.1:
Protocol Counts Percent
--------------------------------
HTTP/0.9 0 0.00%
HTTP/1.0 1,636,187 21.17% (all)
HTTP/1.0 15,415 0.20% (without the obvious robots)
HTTP/1.1 6,091,011 78.83%
HTTP/2 0 0.00%
From what I can see, most of the HTTP/1.0 are from robots. So I tried to remove entries that were obviously from such (i.e. Agent including the word robot, bot, slurp, etc.)
So it looks like the amount of end users still stuck with HTTP/1.0 is very limited today (0.2%). However, if you want to let robots check out your websites, you may need/want to keep HTTP/1.0 operational. Most will anyway include the Host: ... header even though they advertise their connection as an HTTP/1.0 protocol.
Also, the differences between HTTP/1.0 and HTTP/1.1 is very blurry in terms of implementation. Most people are happily mixing both. I would not worry too much about still accepting/handling HTTP/1.0 requests.
On another server I am starting to see HTTP/2.0 requests that look like this (got 2427 and I see 34,161,268 HTTP/1.0 and HTTP/1.1 requests, so 0.007%):
PRI * HTTP/2.0
wget uses HTTP/1.0, and it is still relatively popular (though it does support a few HTTP/1.1 features like the Host: header, which is necessary to access any virtual hosts).
A fair number of servers will deliberately return HTTP/1.0 responses because some (older) browsers will afford a HTTP/1.0 server a higher connection limit than the 2-connection limit imposed for HTTP/1.1's persistent connections.
But in general, most "HTTP/1.0" implementations are really just slightly limited versions of the HTTP/1.1 implementations, and many HTTP/1.1 implementations don't really support some features of that version (e.g. pipelining in particular).
I use it all the time when I'm telnet-ing to a server to verify connectivity or figure out why it's not working:
$ telnet 192.168.1.1 80
GET / HTTP/1.0\r\n
\r\n
...
(Because making a 1.0 request doesn't require that I provide any extra headers).
HTTP/1.0 is very important in writing very basic clients that don't need the overhead of all the 1.1 things like pipelining and other complicated things required by 1.1. Post a request get a response and disconnect is very easy to code for. This might be useful in writing test cases for your server that just want to test the application functionality and NOT the HTTP protocol implementation.
There are lots of mobile browsers and applications that use 1.0 because they don't have the space or need for more sophisticated 1.1 implementations, and the latency issues with non-3G connections on non-smart phones completely negates any benefits of 1.1 features.
There are also lots of proxies that degrade everything to 1.0 regardless of what the client asks for, and then there is IE issues.
So the short answer is, for a general purpose HTTP server, 1.0 is very relevant.
Looking into this myself for other purposes:
"HTTP/1.0 is in use by proxies, some mobile clients, and IE when
configured to use a proxy. So 1.0 appears to still account for a non-
trivial % of traffic on the web overall.
...
Yes, there are many 1.0 clients still out there."
Source (July 2009): http://groups.google.com/group/erlang-programming/msg/08f6b72d5156ef74
:-(
Update (March 2011):
If you are going to build a client/server thingy, make the client use HTTP/1.1, and make the server accept both 1.1 and 1.0.
Doing web-development, it is a PITA to get clients trying to load a page without the Host header, because I have no way to know which site I am supposed to load :-S
So you better don't build a client like that ;-)
IME its been a very long time since I've seen a true HTTP/1.0 request. (including mobile devices fuzzylollipop).
I say a true request as MSIE still (pretends) to downgrade to HTTP/1.0 by default (unless yo sig in the config) when you connect via a proxy (all the outgoing requests are flagged as HTTP/1.0) - however it still includes HTTP/1.1 specific request headers and respects all the HTTP/1.1 responses.
Curiously, IIS, in a mirror image, happily ignores the HTTP version (although I've not experimented much with this to see if only does this for MSIE user agents).
So by curious coincidence, MSIE and IIS work much better with proxies than with standards-compliant tools.
C.