This encoding header tells a web server to send gzip content if available.
'accept-encoding': 'gzip,deflate,sdch',
How can I instruct the web server to send plain text and not gzip the content?
I am aware that the web server can simply ignore this request if it wanted to.
Not including the accept-encoding header implies that you may want the default encoding, i.e. identity. The caveat here is that the RFC2616 sec 14.3 allows the server to assume any available encoding is acceptable.
To explicitly request plain text, set 'accept-encoding: identity'
Leaving the encoding out of accept-encoding will disallow that encoding (ie gzip).
If you want to explicitly set it as disallowed, you can set a qvalue of 0.
'accept-encoding': 'gzip;q=0,deflate,sdch'
You can read more under accept-encoding in RFC2616, but in short if the server can't find an acceptable encoding among the ones listed (identity being a special case, see the link), it should send a 406 (Not Acceptable) response and not reply to your request with any other encoding.
Related
I have a web service that a customer calls with no Accept-Encoding header today. By default, IIS gzips responses back unless the server is under too much load, in which case the responses go back uncompressed (as is consistent with the spec):
The server is overloaded and cannot afford the computational overhead
induced by the compression requirement. Typically, Microsoft
recommends not to compress if a server use more than 80 % of its
computational power.
However, their system doesn't appear able to handle this 'dynamic' response. They say they can either request gzip and get gzip back or request uncompressed and get that back. It doesn't appear we can FORCE our server to respond with gzip so the alternative is to uncompress all responses.
I'm not a low-level HTTP expert so, is this the sort of Accept-Encoding header I could use to force uncompressed responses?
Accept-Encoding: identity;q=1.0, *;q=0.0
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.
I thought this was a simple google search, but apparently I'm wrong on that.
I've seen that you should supply:
Accept-Encoding: gzip;q=0,deflate;q=0
in the request headers. However, the article that suggested it also noted that proxies routinely ignore that header. Also, when I supplied it to nginx, it still compressed the response message body.
http://forgetmenotes.blogspot.ca/2009/05/how-to-disable-gzip-compression-in.html
So, how do I tell a web server to disable compression on the response message body?
Many web servers ignore the 'q' parameter. The compressed version of a static resource is often cached and is returned whenever the request accepts it. To avoid getting compressed resources, use
Accept-Encoding: identity
The server should not serve you a compressed representation of the resource in this instance. Nor should any proxy. This is the default accepted encoding if none is given, but your client might add a default that accepts gzip, so explicitly providing 'identity' should do the trick.
Do you wish encoding to be disabled altogether?Then skip the Accept-Encoding header itself within http request headers.
Do you wish only gzip compression to be absent in the http response?Then skip gzip from the values list in the http request header.
Do you wish to prioritize different compression techniques that servers support? then use different values between 0 and 1 along-with q argument for each value in the Accept-Encoding http request header. (Currently you are using conflicting value and indicating by weight=0 that you don't know how you'll manage, but you want response to be encoded anyhow)
I think this mod for apache
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html (2)
And this for Nginx
http://wiki.nginx.org/HttpGzipModule (1)
Sounds like what you need depending on which server you plan to use. The rest is up to you!
Please note the nginx module both allows shutting down decompression:
[edit] gzip
Syntax: gzip on | off
Default: off
Context: http
server
location
if in location
Reference: gzip
Enables or disables gzip compression.
And dealing with proxies:
[edit] gzip_proxied
Syntax: gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ...
Default: off
Context: http
server
location
Reference: gzip_proxied
It allows or disallows the compression of the response for the proxy request in the dependence on the request and the response. The fact that, request proxy, is determined on the basis of line "Via" in the headers of request. In the directive it is possible to indicate simultaneously several parameters:
off - disables compression for all proxied requests
expired - enables compression, if the "Expires" header prevents caching
no-cache - enables compression if "Cache-Control" header is set to "no-cache"
no-store - enables compression if "Cache-Control" header is set to "no-store"
private - enables compression if "Cache-Control" header is set to "private"
no_last_modified - enables compression if "Last-Modified" isn't set
no_etag - enables compression if there is no "ETag" header
auth - enables compression if there is an "Authorization" header
any - enables compression for all requests
[edit] gzip_types
Best wishes!
Sources:
1) http://forum.nginx.org/read.php?11,96472,214303
2) http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#inflate (Section Output Decompression)
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).
An HTTP server uses content-negotiation to serve a single URL identity- or gzip-encoded based on the client's Accept-Encoding header.
Now say we have a proxy cache like squid between clients and the httpd.
If the proxy has cached both encodings of a URL, how does it determine which to serve?
The non-gzip instance (not originally served with Vary) can be served to any client, but the encoded instances (having Vary: Accept-Encoding) can only be sent to a clients with the identical Accept-Encoding header value as was used in the original request.
E.g. Opera sends "deflate, gzip, x-gzip, identity, *;q=0" but IE8 sends "gzip, deflate". According to the spec, then, caches shouldn't share content-encoded caches between the two browsers. Is this true?
First of all, it's IMHO incorrect not to send "Vary: Accept-Encoding" when the entity indeed varies by that header (or its absence).
That being said, the spec currently indeed disallows serving the cached response to Opera, because the Vary header does not match per the definitions in HTTPbis, Part 6, Section 2.6. Maybe this is an area where we should relax the requirements for caches (you may want to follow up on the IETF HTTP mailing list...
UPDATE: turns out that this was already marked as an open question; I just added an issue in our issue tracker for it, see Issue 147.
Julian is right, of course. Lesson: Always send Vary: Accept-Encoding when sniffing Accept-Encoding, no matter what the response encoding.
To answer my question, if you mistakenly leave Vary out, if a proxy receives a non-encoded response (without Vary), it can simply cache and return this for every subsequent request (ignoring Accept-Encoding). Squid does this.
The big problem with leaving out Vary is that If the cache receives an encoded variant without Vary then it MAY send this in response to other requests even if their Accept-Encoding indicates the client can not understand the content.