httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: thoughts on ETags and mod_dav
Date Thu, 18 Oct 2007 18:52:03 GMT
Nick Kew wrote:

> My vote goes to r->notes.
> Anything else relies on something with semantic significance that'll
> risk breaking random things.
> For the future (e.g. 2.4), we could review other options.  For example,
> abstract out r->finfo to a void* with an API for inspecting resources
> including but not limited to those visible in the filesystem.

   Sounds good; maybe an r->notes key named "NON_EXTANT_RESOURCE" or
"NO_RESOURCE" or some such?

> Feel free to ignore my totally half-baked ideas, but mod_dav is not
> the only area where we have issues, with ETags.  There's also the
> whole question of negotiated content to consider, and I'm still confused
> by the problems that still surround PR#39727.  If we're reworking
> ETag logic, we should take the opportunity to deal with this, too.
> Can we incorporate some kind of tokenisation into ETags that will
> express dependence on negotiation?
> For example, Henrik Nordstrom suggests ";gzip".  If we expand that to,
> say, ";CE=gzip", then we can start to apply semantics to decoding the
> Etag, and determine equivalence.  So in that case, we could determine
> that the (uncompressed) file does indeed match the ETag.  Not sure if
> there's anything we might do with other negotiated headers, but maybe
> we could leave that open, providing a hook that something like
> mod_negotiation might someday use.

   I confess I've been following this discussion at an abstract
level only (at best).  I don't think, though, that it directly affects
any of the several bugs I'm hoping to tackle, if I understand the
issue correctly.  But I don't claim to fully understand the details of


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message