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.
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
In ASP.NET, how can I find out at runtime whether a client is connecting using HTTP 2 or not?
Interestingly I can't find any relevant properties on System.Web.HttpRequest (only had a cursory look). You'll want to dig around that and see if there isn't anything new in the vnext APIs, depending on what you're using.
You can also sidestep the potential lack of API if you're using OWIN. The standard mandates a owin.RequestProtocol property to be set in the request data.
In ASP.NET you can access an OwinContext object that represents those properties from anywhere with HttpContext.Current.GetOwinContext(). Alternatively, you can make it accessible by other means (e.g. dependency injection) yourself. This will depend on your environment, look for the OWIN startup class with Katana and vnext.
Install a plugin for HTTP/2 and SPDY ON your Chrome Browser. The plugin will have a lightning symbol in the url address bar. If the lightning symbol becomes blue, it indicates that the communication is happening over HTTP/2.0 . Green color indicates SPDY connection.
For Firefox, go to Developter tools options -> Network, and then connect to the server. You will find Upgrade - h2 on your Response Header . The upgrade h2 indicates that your client is running HTTP/2.0 with your server.
Apparently we are turning off support of TLS < 1.2 in the near future. So, we would like to inform users that access our site, prior to the turn off, to upgrade their browsers.
Initially I looked at HowsMySSL.com, which has an API that can be accessed via Javascript, but ultimately we don't want to access a 3rd party API.
Is there not a server variable in ASP.NET, which indicates which cipher version has been handshaken between the client and server?
To reiterate, we haven't turned off TLS < 1.2 YET, but want to be proactive to inform those users that will be affected. So, the users will successfully negotiate the handshake, I'm just looking to get the value of the cipher used...
See this thread (oh the futility!): Check ssl protocol, cipher & other properties in an asp.net mvc 4 application
We haven't come up with a solution yet either. Though the SCHANNEL event-log parsing is looking like a promising way to at least get a feel for how many people are connecting with which protocol.
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.