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 mod_negiotiation. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
