Henrik Nordstrom wrote: > On fre, 2007-10-12 at 00:25 -0400, Chris Darroch wrote: > >> RFC 2616 section 14.24 (and 14.26 is similar) says, "If the request >> would, without the If-Match header field, result in anything other than a >> 2xx or 412 status, then the If-Match header MUST be ignored." Thus in >> the typical case, if a resource doesn't exist, 404 should be returned, >> so ap_meets_conditions() doesn't need to handle this case at all. > > There is more to HTTP than only GET/HEAD. > > If-Match: * > and > If-None-Match: * > > is quite relevant only taking 2616 into account
Agreed -- by "in the typical case", I didn't mean "in all cases covered by RFC 2616", although I don't think I made that particularly clear. I just meant that ap_meets_conditions() was likely written with the methods that handled by the core handler in mind; that's why its logic has remained largely unchanged for many years. PUT isn't supported by the core handler, or most "typical" content handlers. WebDAV happens to bring this issue to light, perhaps because it's increasingly widely utilized. I'm all in favour of trying to make ap_meets_conditions() as generic and correct as possible, as I said: > Personally, I'd be inclined to try to make ap_meets_conditions() > handle support these different situations in as generic a way as > possible But, to do this it may be necessary to have data available that isn't at present. That's why I was interested in exploring various options, such as using r->no_local_copy. Or, possibly, we could add an r->does_not_exist flag which would be 0 by default; this could be introduced without compability problems, I think. Modules which needed to indicate that they were dealing with a resource that didn't exist, e.g., lock-null resources in mod_dav, could set the flag to 1. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
