[PATCH] hgweb: add remoteuser to template variables

[Laurens Holst]

  Op 17-9-2010 14:04, FZiegler schreef:
> Dirkjan Ochtman wrote:
>> On Fri, Sep 17, 2010 at 05:16, FZiegler <zarf at klacto.net> wrote:
>>> mpm pointed out a side effect: currently, "If multiple different 
>>> users hit
>>> the same hgweb page through a proxy using existing user-less templates,
>>> they'll get cached copies. The above change will mean they'll all get
>>> uncached copies of the same bytes."
>>>
>>> If that is a concern, I guess we could try to make the ETag addition
>>> conditional on some flag to be set in hgweb.config. As mpm said, 
>>> "Dunno if
>>> it's worth the trouble", I'm leaving this up for you to judge.
>>
>> We could make it conditional on REMOTE_USER being set, that would
>> sufficiently minimize the impact, I think.
>
> I believe it already is, kind of. More precisely, if REMOTE_USER is 
> not set then I'm only causing a one-time change of the ETag, 
> '1283856267.0' --> '1283856267.0/'. So unless I misunderstand (that 
> happened before) the only extra thing I could make conditional in that 
> case is the slash.
>
> You can try it by visiting this URL (same app but no auth middleware): 
> http://sandbox.klacto.net/mathg_bare/Flask/MiniTwit/
>
>> Actually, I wonder if we can leverage the HTTP Vary header to fix this
>> instead of changing the ETag... Maybe you can check that out?
>
> Reading on it as we speak, but still much confused. I have REMOTE_USER 
> in the environment, but I'm not seeing it as a *request header* -- and 
> apparently only those can go in the Vary header:
>
> "The Vary header defines which request headers a cache mechanism 
> should take into account when building its cache key." [1]
>
> Then again, if we somehow get REMOTE_USER into this header instead of 
> in the ETag, that would still turn caching off in mpm's scenario, right?

Sending Vary: X with the response means that the response content varies 
based on request header X. Typically this is used for content 
negotiation based on language, requested type, etc. (Whether browsers 
respect this header is a different matter by the way, I would test that.)

*If* the value of REMOTE_USER is based on HTTP Authentication, Vary: 
Authorization might work. Although I think for Digest authentication 
this might mean that no response will be cached, not sure.

Note that unless certain specific conditions are fulfilled, shared 
caches (like caching proxies) will not cache HTTP-authenticated pages.

Also I could imagine that browsers themselves also don’t cache pages 
that were retrieved with different credentials. But I might be wrong 
there, I could not find such requirement in the HTTP specification.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100917/3aa7194b/attachment.bin>