Changes between Initial Version and Version 1 of Ticket #826, comment 3


Ignore:
Timestamp:
07/15/16 18:09:12 (8 years ago)
Author:
Anders Carling

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #826, comment 3

    initial v1  
    11I agree that adding a configuration option seems overkill, but I would seriously considering bumping the number.
    22
    3 A reasonable Vary-header for many sites might be "Accept,Accept-Encoding,Accept-Language" (38 bytes). Tthat's really only using standard headers and almost hits the limit.
     3A reasonable Vary-header for many sites might be {{{Accept,Accept-Encoding,Accept-Language}}} (38 chars). Tthat's really only using standard headers and almost hits the limit.
    44
    5 The longest Very-header we (an api) emit in production (for a request we expect to cache at least) is "Accept,Accept-Encoding,X-TummyLab-API,X-TummyLab-Last-Response-Identifier" (73 chars) - but at some point we'll probably throw at least Accept-Language in there and probably something more.
     5The longest Very-header we (an api) emit in production (for a request we expect to cache at least) is {{{Accept,Accept-Encoding,X-TummyLab-API,X-TummyLab-Last-Response-Identifier}}} (73 chars) - but at some point we'll probably throw at least Accept-Language in there and probably something more.
    66
    77A secondary issue is that no error logging at all is done when the request is marked as uncachable, which makes this "issue" really hard to detect. I just found it by dumb luck after introducing a new header to Vary.