Requests, which would be just as bad as not changing ETag. Likewise, removing etags for the entire configured scopeĪllows clients to use the last-modified timestamp for range Unfiltered content has an ETag but the filtered contentĭoes not, which puts us back to the point of messing upĪ cache that is checking the 304 response for consistency. So complex that we are better off deleting the module.įinally, we can't just remove the ETag because then the Unique id to the suffix, either, since we need the tag to Set the suffix and how many caches have stored the modifiedĮTag versus the unmodified ETag. In a chain of Apache servers, we won't know which server Preprocessing all incoming conditional headers to removeĪ -gzip suffix before the request is processed won't work. Request header fields, as DEFLATE/INFLATE does for responses. That it would activate under the same conditions, based on the Input filter whenever the output filter is configured and ensure Processing is begun, especially if the request has been Of the response, so there is no clear way of selectively inflatingĪ corresponding PUT or conditional request before the request The problem here is that the DEFLATE filter is usuallyĪdded after the request is processed, based on the media type If mod_deflate modifiesĮTag on the way out, then its corresponding later requests mustīe reverse-modified (etags and request content) on the way back. Mod_deflate is written as a content filter that can be arbitrarilyĪdded to the output chain after the request is processed, justīefore the body goes out on the wire. Transfer-Encoding to HTTP as the proper way to do on-the-fly On-the-fly content-encoding is a stupid idea, and why I added Requests regarding that content (e.g., PUT or conditional GET) (neither "never" nor "always) makes it impossible for later The only good answer is "don't use mod_deflate" becauseĬhanging content-encoding on the fly in an inconsistent manner Motivating this report is a no-win situation no matter how it is The HTTP syntax error has been fixed in trunk, but the problem Squid-2.6 and later is ETag aware and will make this problem quite visible. * Clients doing range requests with If-Range may end up with corrupted objectsĬontaining part compressed part plain content. Request so mod_deflate can not tell if the If-None-Match condition is on a (same ETag used in both responses -> Same If-None-Match Response is given to all clients as If-None-Match indicates the entitiy is OKįor all clients. * Clients may be given the incorrect response. Same request with "Accept-Encoding: gzip": If-Range ranges in gzip:ed entity obviously not the same as ranges inĮxample HTTP responses from an Apache-2.2.2 mod_deflate enabled server If-None-Match used in Vary negotiation from ETag aware caches This has implications on at least the following HTTP directives: Each negotiated variant (whereĪccept-Encoding is just one negotioantio parameter) needs to have unique ETag:s.įor mod_deflate it's as simple as adding the encoding to the already computed ETag. It is very important each unique entity carries unique ETag:s as these identify If you want a broader understanding of which features we are most likely to accept, see The Feature Acceptance Test.Entities gzip:ed by mod_deflate still carries the same ETag as the plain entiy,Ĭausing inconsistency in ETag aware proxy caches. If the priority of a bug isn't set, and you want it to be, come ask us in our chat rooms. If a posted patch involves any significant complexity, it will likely be rejected. If somebody implements it and asks for review, we might look at it. If the patch proves to be too complex, there's a chance that the feature will be marked WONTFIX or delayed until some unknown future release. We would review a patch if somebody posted it, but a core developer is unlikely to work on it. P4 = This isn't a terrible idea, but it's not important to our long-term plans for Bugzilla.Some core Bugzilla developer may work on it. P3 = This isn't a bad idea, and maybe we'll want to implement it at some point in the future, but it's not near-term roadmap material.P2 = We want this, but it's not totally clear or extremely important.It's a major feature, and it's obvious that it would be useful to everybody. We have a Priority system for enhancements: This page only covers the main Bugzilla project. Warning: If you are looking for information about priorities of bugs in Firefox and other Mozilla products, please see the triage process page.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |