If I make a GET request via netcat without specifying the http version - GET /, I get a response from the server without it waiting for me to send any headers and a blank line first. But if the version is there - GET / HTTP/0.1, it behaves normally, even if it's 0.1. I tested it on google.com, apache.org and microsoft.com. Is it defined by the protocol?
This form of request (GET / without a version) was used by an early version of the HTTP protocol, known as HTTP/0.9, which did not support headers at all. See The Original HTTP as defined in 1991.
Later specs for HTTP 1.0 (RFC 1945) and HTTP 1.1 (RFC 2616) require HTTP 1.0+ implementations to recognize HTTP 0.9 requests and responses (RFC 7230 for HTTP 1.1 later dropped that requirement).
RFC 1945 states:
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.
How does HTTP 1.1 server should respond to a HTTP 1.0 request for headers like Pragma : no-cache which are supported in HTTP 1.0 but not in HTTP 1.1
If we assume that the HTTP 1.1 server wants to be backward compatible with HTTP 1.0 clients, then the HTTP 1.1 server would send a HTTP 1.0 response to HTTP 1.0 clients.
For example, let's assume that your HTTP 1.0 client sends a request like this:
GET /path/to/resource HTTP/1.0
Notice that the last part of the request is "HTTP/1.0", indicating the client's supported HTTP version. We'll get back to this, but it's important.
Your HTTP 1.1 server might normally want to use the Cache-Control response header to disable any caching, e.g.:
HTTP/1.1 200 OK
Cache-Control: no-cache
But Cache-Control is not supported for HTTP 1.0 requests, and the above response indicates that it is an HTTP 1.1 response, which is odd, given the HTTP 1.0 request.
So instead, the HTTP 1.1 server would have to generate an HTTP 1.0 compliant response, like so:
HTTP/1.0 200 OK
Pragma: no-cache
The HTTP 1.1 server ideally pays attention to the HTTP version in the request, and constructs a response that is appropriate for that HTTP version. For an older client (.e.g. HTTP 1.0) communicating with a newer, backward-compatible server (e.g. HTTP 1.1), this works.
What happens, though, if it's a newer client talking to an older server, such as an HTTP 1.1 client talking to an HTTP 1.0 server? In that case, the request might be:
GET /path/to/resource HTTP/1.1
Host: example.com
Cache-Control: no-cache
The HTTP 1.0 server won't know about the Cache-Control header, or any other HTTP 1.1-isms. In this case, the HTTP 1.0 server might reject the response using "400 Bad Request" (or some other similar non-success response code) because of the version incompatibility, or the server might issue an HTTP 1.0 response to the HTTP 1.1 request:
HTTP/1.0 200 OK
Pragma: no-cache
The actual behavior you see will depend on the client and server implementations involved.
Hope this helps!
Is it alright to respond with HTTP/1.0 to HTTP/1.1 request?
I am implementing HTTP communication through simple sockets and clients make requests with both HTTP/1.0 and HTTP/1.1 but protocol is independent of HTTP version so I want to always respond with HTTP/1.0 to all requests.
Does HTTP standard bear such communication?
Of course it's alright. Otherwise, if you only supported HTTP/1.0, what could you do?
If HTTP 1.2 came out today, what do you think all existing HTTP 1.1 servers would send as replies to HTTP 1.2 queries? Of course, it'll have to be HTTP 1.1 replies -- that's all they know how to do.
Just make sure you don't follow HTTP 1.1 rules where they differ. For example, keep alives are not enabled by default. If a client sees an HTTP 1.0 reply, it will assume HTTP 1.0 semantics.
Fairly simple question (I think). If a client sends a message like GET /whatever HTTP/1.1 to a server that only supports HTTP 1.0, how does the server react? What are the rules for header fields added in HTTP 1.1 that a HTTP 1.0 server doesn't recognise? Does the server simply ignore 1.1 requests, ignore headers it doesn't understand, return an error, or something else?
HTTP/1.0 200 OK
All headers of HTTP/1.1 (that a HTTP 1.0 server doesn't recognise) will be ignored.
Could somebody give me a brief overview of the differences between HTTP 1.0 and HTTP 1.1? I've spent some time with both of the RFCs, but haven't been able to pull out a lot of difference between them. Wikipedia says this:
HTTP/1.1 (1997-1999)
Current version; persistent connections enabled by default and works well with proxies. Also supports request pipelining, allowing multiple requests to be sent at the same time, allowing the server to prepare for the workload and potentially transfer the requested resources more quickly to the client.
But that doesn't mean a lot to me. I realize this is a somewhat complicated subject, so I'm not expecting a full answer, but can someone give me a brief overview of the differences at a bit lower level?
By this I mean that I'm looking for the info I would need to know to implement either an HTTP server or application. I'm mostly looking for a nudge in the right direction so that I can figure it out on my own.
Proxy support and the Host field:
HTTP 1.1 has a required Host header by spec.
HTTP 1.0 does not officially require a Host header, but it doesn't hurt to add one, and many applications (proxies) expect to see the Host header regardless of the protocol version.
Example:
GET / HTTP/1.1
Host: www.blahblahblahblah.com
This header is useful because it allows you to route a message through proxy servers, and also because your web server can distinguish between different sites on the same server.
So this means if you have blahblahlbah.com and helohelohelo.com both pointing to the same IP. Your web server can use the Host field to distinguish which site the client machine wants.
Persistent connections:
HTTP 1.1 also allows you to have persistent connections which means that you can have more than one request/response on the same HTTP connection.
In HTTP 1.0 you had to open a new connection for each request/response pair. And after each response the connection would be closed. This lead to some big efficiency problems because of TCP Slow Start.
OPTIONS method:
HTTP/1.1 introduces the OPTIONS method. An HTTP client can use this method to determine the abilities of the HTTP server. It's mostly used for Cross Origin Resource Sharing in web applications.
Caching:
HTTP 1.0 had support for caching via the header: If-Modified-Since.
HTTP 1.1 expands on the caching support a lot by using something called 'entity tag'.
If 2 resources are the same, then they will have the same entity tags.
HTTP 1.1 also adds the If-Unmodified-Since, If-Match, If-None-Match conditional headers.
There are also further additions relating to caching like the Cache-Control header.
100 Continue status:
There is a new return code in HTTP/1.1 100 Continue. This is to prevent a client from sending a large request when that client is not even sure if the server can process the request, or is authorized to process the request. In this case the client sends only the headers, and the server will tell the client 100 Continue, go ahead with the body.
Much more:
Digest authentication and proxy authentication
Extra new status codes
Chunked transfer encoding
Connection header
Enhanced compression support
Much much more.
HTTP 1.0 (1994)
It is still in use
Can be used by a client that cannot deal with chunked
(or compressed) server replies
HTTP 1.1 (1996- 2015)
Formalizes many extensions to version 1.0
Supports persistent and pipelined connections
Supports chunked transfers, compression/decompression
Supports virtual hosting (a server with a single IP Address hosting multiple domains)
Supports multiple languages
Supports byte-range transfers; useful for resuming interrupted data
transfers
HTTP 1.1 is an enhancement of HTTP 1.0. The following lists the
four major improvements:
Efficient use of IP addresses, by allowing multiple domains to be
served from a single IP address.
Faster response, by allowing a web browser to send multiple
requests over a single persistent connection.
Faster response for dynamically-generated pages, by support for
chunked encoding, which allows a response to be sent before its
total length is known.
Faster response and great bandwidth savings, by adding cache
support.
For trivial applications (e.g. sporadically retrieving a temperature value from a web-enabled thermometer) HTTP 1.0 is fine for both a client and a server. You can write a bare-bones socket-based HTTP 1.0 client or server in about 20 lines of code.
For more complicated scenarios HTTP 1.1 is the way to go. Expect a 3 to 5-fold increase in code size for dealing with the intricacies of the more complex HTTP 1.1 protocol. The complexity mainly comes, because in HTTP 1.1 you will need to create, parse, and respond to various headers. You can shield your application from this complexity by having a client use an HTTP library, or server use a web application server.
A key compatibility issue is support for persistent connections. I recently worked on a server that "supported" HTTP/1.1, yet failed to close the connection when a client sent an HTTP/1.0 request. When writing a server that supports HTTP/1.1, be sure it also works well with HTTP/1.0-only clients.
One of the first differences that I can recall from top of my head are multiple domains running in the same server, partial resource retrieval, this allows you to retrieve and speed up the download of a resource (it's what almost every download accelerator does).
If you want to develop an application like a website or similar, you don't need to worry too much about the differences but you should know the difference between GET and POST verbs at least.
Now if you want to develop a browser then yes, you will have to know the complete protocol as well as if you are trying to develop a HTTP server.
If you are only interested in knowing the HTTP protocol I would recommend you starting with HTTP/1.1 instead of 1.0.
HTTP 1.1 is the latest version of Hypertext Transfer Protocol, the World Wide Web application protocol that runs on top of the Internet's TCP/IP suite of protocols. compare to HTTP 1.0 , HTTP 1.1 provides faster delivery of Web pages than the original HTTP and reduces Web traffic.
Web traffic Example: For example, if you are accessing a server. At the same time so many users are accessing the server for the data, Then there is a chance for hanging the Server. This is Web traffic.
HTTP 1.1 comes with the host header in its specification while the HTTP 1.0 doesn't officially have a host header, but it doesn't refuse to add one.
The host header is useful because it allows the client to route a message throughout the proxy server, and the major difference between 1.0 and 1.1 versions HTTP are:
HTTP 1.1 comes with persistent connections which define that we can have more than one request or response on the same HTTP connection.
while in HTTP 1.0 you have to open a new connection for each request and response
In HTTP 1.0 it has a pragma while in HTTP 1.1 it has Cache-Control
this is similar to pragma