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.
Related
In HTTP 1.1, the status line was
scheme/version code reason
HTTP/1.1 200 OK
I see :scheme and :status headers in the HPACK spec. I don't however see anything for version or reason? Is there not one?
In a request in HTTP 1.1, the request line was
method uri scheme/version
POST http://myhost.com HTTP/1.1
I see :method and I see :path, which I think is just a relative path, which is not the same as the full absolute path (and since Chrome and Firefox are pushing HTTPS for HTTP/2, this may make sense). I do not see version header though.
Is there a version header? Or is it seen that this will always be known before the protocol decision such that it is not really needed?
What about reason codes? Is it assumed these are pretty constant so that goes away (I am guessing here)?
In HTTP/1, the version token was needed to differentiate HTTP/1.0 from HTTP/1.1, since they had the same wire representation, but were supporting different features.
For example, a client declaring HTTP/1.1 implicitly tells the server that it supports persistent connections and content chunking.
With HTTP/2, the protocol version is negotiated.
In clear-text HTTP/2, the Upgrade header reports h2c, where the 2 means version 2 of the protocol. I imagine that for HTTP/3 the token will change to h3c.
Similarly happens for encrypted HTTP/2 where the token h2 is negotiated via ALPN.
Reason messages have been dropped as being redundant, as the status code was already conveying all the necessary information (not to mention that they could be attack vectors).
For these reasons, HTTP/2 does not have neither version nor reason pseudo-headers.
Is there an easier way of getting the content of an HTTP 404 response than directly accessing the host via tcp?
This is a sample of a 404 response with content:
HTTP/1.1 404 Object Not Found
Server: CouchDB/1.3.0 (Erlang OTP/R15B03)
Date: Wed, 24 Jul 2013 08:32:50 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 41
Cache-Control: must-revalidate
{"error":"not_found","reason":"missing"}
The Rebol HTTP scheme really isn't designed with this in mind, it's geared toward reading content the way you would in a browser, not services over HTTP.
In saying that, you can hack the protocol to subvert how Rebol 2 handles different response codes:
in-http-scheme: func [does [block!]][
do bind :does bind? last body-of get in system/schemes/http/handler 'open
]
in-http-scheme [
remove-each [code response] response-actions [find [400 403 404] code]
append response-actions [400 success 403 success 404 success]
]
The caveat here is that the HTTP protocol has to have been initiated (any http port opened/read). response-actions can still be accessed when http has not been initiated:
select body-of get in system/schemes/http/handler 'open quote response-actions:
You can get the last response line thus:
in-http-scheme [response-line]
Alternatively you are going to need a scheme designed for services over HTTP. I have a REST protocol (two versions, one that uses cURL, and one that uses a customised HTTP scheme that works, but isn't as good). Though are for Rebol 2. I have plans for a Rebol 3 version.
Christopher Ross-Gill has created a REST protocol for Rebol which allows simple access to all headers and even handles OAuth. Have a look at the details here.
http://www.ross-gill.com/page/REST_Protocol
Unfortunately it is only for Rebol 2 at the moment and it depends on the use of curl for the http requests.
All,
My requirement is fairly simple. I have to perform a simple HTTP POST to an IP:port combination. I used simple socket programming to do that and I have been successful in sending across my request to them and also get back response from them. The only problem being that the response is always a HTTP 400: Bad Request followed by my HTTP POST message. I am not sure if the problem is with the client or the server. My only guess being that there might be a problem with my data that I am sending. This is what my POST looks like
POST /<Server Tag> HTTP/5.1
Content-Length: xxx
--Content--
and the response from the server looks something like this
HTTP/1.1 400 Bad Request
Content-Length: xxx
--Same content that I sent them--
I was not sure If I could put in the IP of the server here so kept myself to using . I am pretty sure that the problem would not be there since I get back some response from the server and confident about the connection. Can someone help me ?
PS: Some pointers about my POST:
1) HTTP 5.1 was requested by the server and I am not sure if that is correct
2) I have played around with the number of line spaces after the content length. I have tried giving one and two lines. Not sure if that would make a difference. On wireshark though I see a difference with the number of line spaces as with a single line space the protocol is specified as TCP but with two it changes to HTTP. The response is always received on HTTP protocol. Some explanation on the difference would also help
Thanks
edit: the other thing that confuses me is that the response has a HTTP 1.1 and not a 5.1 that I had sent. I have also tried changing my post to 1.1 with no success
edit2: Based on suggestion form fvu and others, I used WebClient to Upload my request. Still got back a 400. The header that was generated by the WebClient looks like this
POST <server tag> HTTP/1.1
Host: <IP:PORT>
Content-Length: 484
Expect: 100-continue
Connection: Keep-Alive
The issue I see with this might be that the server was not expecting all the details in the header. The server has requested only the Content-Length from us. Would that be a problem?
Thanks
You can use a debugging proxy to view a client request and a server response to figure out what your client socket program needs to do.
But first you need to create a simple web page that a browser displays, allows you to do a POST from the browser to the web server, and get a simple response back from the server.
HTTP/5.1 is either wrong or misused by the programmer of the server application
You should get a valid example from the server api to check your protocol implementation first.
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.
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.