Timeline for Server has stopped obeying Accept-encoding header
Current License: CC BY-SA 2.5
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 15, 2010 at 12:30 | comment | added | Kevin Montrose | @Artefacto - you're ignoring the case where a proxy inserts an Accept-Encoding other than the one the client initially sent. This does happen, though somewhat less frequently than simply stripping it out. | |
| Jun 15, 2010 at 11:40 | comment | added | Artefacto | I'm specifically saying I do not accept any encoding, yet you refuse. Don't you think an error is due? The RFC says it should be, and apparently there are no "real world issues" in this particular case. I think these are enough reasons. | |
| Jun 15, 2010 at 11:21 | comment | added | Kevin Montrose | @Artefacto - ... why? We already deviate from the spec to work around real world issues, why throw more error conditions out there? | |
| Jun 15, 2010 at 11:17 | comment | added | Artefacto |
I'm not following. If the proxies strip the Accept-Encoding header, then by all means send the gziped response. But if an Accept-encoding: none header reaches you, send a 406. No Accept-Encoding header <> Accept-encoding: none. In particular, RFC 2616 says "If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding."
|
|
| Jun 15, 2010 at 11:12 | history | answered | Kevin Montrose | CC BY-SA 2.5 |