- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 29 Jul 2008 19:02:37 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > > http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80 > > > On 01/08/2007, at 2:17 AM, Julian Reschke wrote: > >> the definition of Content-Location >> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.14.p.7>) >> ends with: >> >> "The meaning of the Content-Location header in PUT or POST requests is >> undefined; servers are free to ignore it in those cases." >> >> This was added in RFC2616 (does not appear in RFC2068). >> >> I have no problem allowing servers to ignore it. However: >> >> 1) It seems that the meaning of Content-Location is universal for >> messages that carry an entity; I'm not sure what's the point in >> claiming that meaning does not apply to PUT or POST. >> >> 2) Also: every time a limited set of methods is mentioned somewhere it >> feels like problematic spec writing. What makes PUT or POST so special >> in comparison to other methods? Maybe that they are the only methods >> in RFC2616 that carry request entity bodies? In which case the >> statement should be rephrased accordingly... > ... Proposal: just drop "PUT and POST" from the sentence, making it: "The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases." BR, Julian
Received on Tuesday, 29 July 2008 17:03:21 UTC