Changes between Initial Version and Version 1 of Ticket #377, comment 11


Ignore:
Timestamp:
12/14/13 20:17:53 (11 years ago)
Author:
Michael Fischer

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #377, comment 11

    initial v1  
    1 I respectfully disagree; I think the Apache solution is adequate.  The debate regarding weak vs. strong ETags was exhaustively argued by the Apache team in https://issues.apache.org/bugzilla/show_bug.cgi?id=39727, and their resulting decision to append the -gzip suffix has not caused any reported problems.  The fact that there was so much discussion over it suggests the RFC is not completely clear on the subject so they had to make a decision, that it has not proved to be a bad one (i.e. it hasn't caused problems with intermediary caching).
     1I respectfully disagree; I think the Apache solution is adequate.  The debate regarding weak vs. strong ETags was exhaustively argued by the Apache team in https://issues.apache.org/bugzilla/show_bug.cgi?id=39727, and their resulting decision to append the -gzip suffix has not caused any reported problems.  The fact that there was so much discussion over it suggests the RFC is not completely clear on the subject.  Ultimately that team had to make a decision and it has not proved to be a bad one (i.e. it hasn't caused problems with intermediary caching).
    22
    3 The fact of the matter is that any difference in the compressed bytestream is irrelevant to the client; it is the uncompressed representation that the client cares about.
     3The fact of the matter is that any difference in the compressed bytestream is irrelevant to the client for the purpose of generating If-None-Match requests; it is the uncompressed representation that the client cares about.
    44
    55Given that there is already one HTTP reference implementation that has behaved this way without ill effect, I think it's a strong argument for nginx to behave this way as well unless it can be demonstrated that it will actually cause real-world problems.