{"action":"opened","issue":{"url":"https://api.github.com/repos/netty/netty/issues/4608","labels_url":"https://api.github.com/repos/netty/netty/issues/4608/labels{/name}","comments_url":"https://api.github.com/repos/netty/netty/issues/4608/comments","events_url":"https://api.github.com/repos/netty/netty/issues/4608/events","html_url":"https://github.com/netty/netty/issues/4608","id":123158021,"number":4608,"title":"Http gzip/deflate compression rules","user":{"login":"kyankovski","id":3605576,"avatar_url":"https://avatars.githubusercontent.com/u/3605576?v=3","gravatar_id":"","url":"https://api.github.com/users/kyankovski","html_url":"https://github.com/kyankovski","followers_url":"https://api.github.com/users/kyankovski/followers","following_url":"https://api.github.com/users/kyankovski/following{/other_user}","gists_url":"https://api.github.com/users/kyankovski/gists{/gist_id}","starred_url":"https://api.github.com/users/kyankovski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kyankovski/subscriptions","organizations_url":"https://api.github.com/users/kyankovski/orgs","repos_url":"https://api.github.com/users/kyankovski/repos","events_url":"https://api.github.com/users/kyankovski/events{/privacy}","received_events_url":"https://api.github.com/users/kyankovski/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-12-20T12:46:43Z","updated_at":"2015-12-20T12:46:43Z","closed_at":null,"body":"Hi Norman!\r\n\r\nWe are using netty4.0-based high-load http server and now we need to add gzip and deflate compression/decompression. That was easy to add such a feature (so it's working pretty well), but I have a question and would like to discuss it.\r\n\r\nThe question is about io.netty.handler.codec.http.HttpContentCompressor#determineWrapper implementation. This method takes into account just a value from \"Accept-Encoding\" header but completely ignores \"Content-Encoding\" request header.\r\n\r\nSo I see there 2 issues:\r\n\r\n--- ISSUE 1 ---\r\n1. Client sends deflate-compressed request with the following headers:\r\nContent-Encoding: deflate\r\nAccept-Encoding: deflate, gzip\r\nContent-Length: 1234\r\nAs I understand the http/1.1 spec it's an absolutely legal case. The first header tells what kind of compression was used for this particular request, the second one tells which content-codings are acceptable for the client.\r\nResponse in this case will be compressed using 'gzip' algorithm, but not 'deflate' (as was request) because qvalue is not defined for both 'deflate' and 'gzip' in the 'Accept-Encoding' header. So the default compressor (gzip) will be used.\r\n\r\nAccording to HTTP/1.1 specification, section 14.3 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html described case-1 is legal because the spec tells to choose an appropriate encoding based on qvalue (\"3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.)\" and do not say what to do if qvalue is equal for several content-codings or is not declared at all. So netty choose the default compressor - gzip.\r\n\r\nFor my humble opinion that is more logical to choose not the default netty compressor (gzip) but look at \"Content-Encoding\" header and response with the same compression (deflate in the my example). It will be also a valid behavior according HTTP/1.1 spec (it tells nothing about missed qvalue). And it will be more predictable behavior for the client. The netty-based server should not worry that non-default gzip compressor is used - the client said that he support both deflate and gzip.\r\n\r\n--- ISSUE 2 --- \r\n2. Client sends compressed request without \"Accept-Encoding\" header headers:\r\nContent-Encoding: gzip\r\nContent-Length: 1234\r\n\r\nIn this case  io.netty.handler.codec.http.HttpContentCompressor wan't apply any compression, but for my humble opinion that is not the best behavior.\r\n\r\nAccording to HTTP/1.1 specification, section 14.3 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html tells:\r\n\"If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if \"identity\" is one of the available content-codings, then the server SHOULD use the \"identity\" content-coding, unless it has additional information that a different content-coding is meaningful to the client.\"\r\n\r\nSo I think in such a case HttpContentCompressor should look not just at \"Accept-Encoding\" but also at \"Content-Encoding\" request header and choose the same compression that was used in the request. The server(netty) should not worry that compressed response won't be recognized by the client because:\r\n1) The client used the compression to send the request\r\n2)  HTTP/1.1 spec says: \"If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding.\"\r\n\r\nFor my humble opinion that is more logical to answer using 'gzip' compression in such case.\r\n\r\n---------\r\n\r\nWhat do you think about it? Do you agree to apply such a change to the netty distribution?\r\n\r\nThanks,\r\nKonstantin"}}