While reading RFC2616, I came across TE and Transfer Encoding headers for chunked encoding. I have following question on these:
If a HTTP Server rejects a request because of presence of TE header, is it RFC compliant?
If a HTTP Client sends a request with TE header and list of t-codings and q values and once such q value is 1, is it mandatory for HTTP server to send the response data with that encoding, for eg: TE: deflat;q=0.5 gzip;q=1 (Does this mandate server to compress entity data in gzip and send it or can server ignore that and send data in normal way?).
If a HTTP server does not support reception of chunked data (I am aware that it goes against RFC, but is intended), what could be the right error response code to be sent back to the client so that client next time does not send PUT request in chunked fashion.
Thanks in advance for your valuable inputs and answers.
In RFC 7230 it says,
The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a
chunked transfer coding.
This infers that TE is simply a declaration by the client and can be ignored by next server. There should be no reason for a HTTP server to reject a request with a TE header. If a server does not support chunked then it does not support HTTP 1.1 and therefore should interpret the incoming request as if it were a 1.0 request and respond accordingly. See here.
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).
I recently saw a GET call which had the Transfer-Encoding header set to Chunked. What we noticed from this call is a delay then a 500 socket timeout.
Digging deeper, we showed this behavior of the 500 coming from ELB's and Apache web servers.
Of note, if we make the GET call with Transfer-Encoding as Chunked and include an empty payload, the ELB in our case allows the request to go through as normal.
Given this ELB's and Apache web servers exihibit this behaviour, my question is sending Transfer-Encoding as Chunked on a HTTP GET call is valid or not?
The Transfer-Encoding header is now under authority of RFC 7230, section 3.3.1 (see also the IANA Message Header Registry. You will find that this header is part of the HTTP message framing, so it is valid for both, requests and responses.
Keeping in mind that GET requests may carry bodies, the reaction of the server(s) is absolutely correct. What is causing the delay followed by the 500 is probably the following: The server would expect a body but fails to find one, since the chunk-encoded representation of an empty string is not an empty string but a zero-sized chunk. In consequence, the server is running into a timeout.
I want to send my response data to to client with "Transfer-Encoding:trunked".
But I do not find the way to do it with Golang.
Is there any example for this?
The net/http server does not allow the application to control the transfer encoding.
The net/http server automatically uses chunked encoding when the application does not set the Content-Length response header and the connection can be reused (http/1 client requested keep-alive or http/1.1 client did not request connection close).
RFC 2616: https://www.rfc-editor.org/rfc/rfc2616#section-8.2.3
An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation.
There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100-continue" expectation. The purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status.
I do not understand that explained purpose. Why the server would send something if it already knows it is not expected ? A client will not know what to do with that if it doesnt expect it. It has no choice but to ignore it. But then, why bother sending it ?
If the client sends a PUT or POST request message that has a body, it will include "Expect: 100-Continue" header if it will wait for a confirmation before sending the body, or it will send the body directly. If it chose to send it directly, the body will be sent before the server can send the "100-Continue" response, and if the client receicve that response when it has nothing left to send, what it would do whit it ?
I've also read the other questions regarding 100-Continue response but I got no answer...
RFC 2068 didn't include the "Expect: 100-continue" header. A server receiving an HTTP 1.1 request was required to send a 100-Continue response before receiving the request body:
Upon receiving a method subject to these requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
respond with 100 (Continue) status and continue to read from the
input stream, or respond with an error status.
Later, RFC 2616 included the Expect header, but allowed servers to send a 100-Continue response for those clients that where implemented before and might be waiting for it.
I asked this question a few days ago, and I didn't get a lot of activity on it. And it got me thinking that perhaps this was because my question was nonsensical.
My understanding of http is that a client (typical a browser) sends a request (get) to a server, in my case IIS. Part of this request is the accept-encoding header, which indicates to the server what type of encoding the client would like the resource returned in. Typically this could include gZip. And if the server is set up correctly it will return the resource requested in the requested encoding.
The response will include a Content-Encoding header indicating what compression has been applied to the resource. Also included in the response is the Content-Type header which indicates the mime type of the resource. So if the response includes both Content-Type : application/json and Content-Encoding: gzip, the client knows that resource is json that is has been compressed using gzip.
Now the scenario I am facing is that I am developing a web service for clients that are not browsers but mobile devices, and that instead of requesting resources, these devices will be posting data to the service to handle.
So i have implemented a Restfull service that accepts post request with json in the body. And my clients send their post requests with Content-Type:Application/json. But some of my clients have requested that they want to compress their request to speed up transmission. But my understanding is the there is no way to indicate in a request that the body of the request has been encoded using gZip.
That is to say there is no content-Encoding header for requests, only responses.
Is this the case?
Is it incorrect usage of http to attempt to compress requests?
According to another answer here on SO, it is within the HTTP standard to have a Content-Encoding header on the request and send the entity deflated.
It seems that no server automatically inflates the data for you, though, so you'll have to write the server-side code yourself (check the request header and act accordingly).