I'm writing a HTTP client which doesn't have any encoding algorithms built into it yet. Therefore, I was wondering if there is a value for Accept-Encoding header to indicate this? like: "none" for example, or "text/plain" or similar ?
You can just omit the Accept-Encoding header if you don't support compression:
http://www.httpwatch.com/httpgallery/compression/
However, this will not prevent some servers sending you chunked encoded responses:
http://www.httpwatch.com/httpgallery/chunked/
on persistent "keep-alive" HTTP connections. You can disable persistent connections by adding a "Connection: close" request header and the server will simply close the connection after all the content has been returned in the response message.
Related
In the wikipedia HTTP header fields:
There list many HTTP header fields, but I did not found a way to distinguish the headers about intermediate system(Such as CDN/HTTP Proxy).
Is there a way to distinguish out the IntermediateSystem-related HTTP header fields? or is there any link introduce it?
All the HTTP headers can send to proxy, there can only distinguished by whether Proxy modify the headers: End-to-end headers and Hop-by-hop headers.
End-to-end headers
These headers must be transmitted to the final recipient of the message: the server for a request, or the client for a response. Intermediate proxies must retransmit these headers unmodified and caches must store them.
Hop-by-hop headers
These headers are meaningful only for a single transport-level connection, and must not be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the Connection general header.
and if you want to find more proxy-related,
from developer.mozilla.org - HTTP Headers:
Headers can also be grouped according to how proxies handle them:
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
TE
Trailer
Transfer-Encoding
Upgrade (see also Protocol upgrade mechanism).
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token.
Could somebody please give an example of a common scenario the above paragraph is referring to?
Does that have anything to do with Connection: close header?
A good example, in HTTP/1.1, is Upgrade, to indicate that a client wishes to move from HTTP/1.1 to another protocol:
GET http://www.example.com/hello.txt HTTP/1.1
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
If this were a proxy, the Upgrade header should not be passed to any upstream servers, as it only makes sense for this connection.
The Keep-Alive header could also appear here in HTTP/1.0 but is now obsolete with HTTP/1.1.
When the field Connection: Keep-Alive is set inside a HTTP request, the connection is not closed after the response is sent.
How does the client and the server knows that the data is over?
The only way I believe this works is by setting the field Content-Length at the HTTP request and the response.
Is there any other way?
My client sets the following headers:
Transfer-Encoding: chunked
Connection: Keep-Alive
When I retrieve responses I receive a Transfer-Encoding: chunked header but no Connection: Keep-Alive header. For this reason I believe I may only be receiving a partial response in my client.
Now my question is:
Is it mandatory to set the Connection: Keep-Alive property in HTTP/1.1 ?
In short, no. In the absence of a Connection header for messages adhering to HTTP/1.1 the default is a persistent Keep-Alive connection. If a connection header is present both parties should act accordingly given that header's value.
As stated by RFC 2616 Section 8.1.2:
A significant difference between HTTP/1.1 and earlier versions of HTTP
is that persistent connections are the default behavior of any HTTP
connection. That is, unless otherwise indicated, the client SHOULD
assume that the server will maintain a persistent connection, even
after error responses from the server.
Of course, this doesn't prevent you from explicitly setting a Connection: close header if you wish to close the connection once the transfer completes.
I read in some articles that if we do not set content-length header in http request,we get the http response in chunks.(Transfer-encoding:chunked which is choosen by server implicitly in such case).In my java code I did not set content-length header.Still I am getting content-length header in my response instead of chunked transfer.please help.
You probably mean "do not set content-length header in http response".
Anyway, a servlet engine is free not to use chunked encoding if it can determine the length of the reponse before sending it.