- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 06 May 2009 10:41:19 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Brian Smith <brian@briansmith.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Mark Baker'" <distobj@acm.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
ons 2009-05-06 klockan 16:15 +1000 skrev Mark Nottingham: > "The meaning of the Content-Location header in requests is undefined; > servers are free to ignore it in those cases." > > It seems like there may be a bit of alignment needed, depending on how > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79> goes... I consider the two pretty much separate. Servers are always free to ignore Content-* headers they understand, and Content-Location is generally no problem if ignored as there is no defined meaning of Content-Location in a PUT. (also it semantically conflicts somewhat with the PUT URI). But I do seriously doubt that anyone implements the Content-* requirements in PUT processing when seeing headers they don't understand or know about... Because of this I propose that 79 is resolved by downgrading these to SHOULD level (both of them). It's a good rule, and makes sense when implemented, but as many don't clients cant really rely on servers implementing it, but may still have it as a requirement for using the client. But I don't expect this to have much of a significant effect on actual use of PUT. In most uses there is some form of negotiation (mostly out-of-band in file extensions etc) on the URL to PUT to for storing content with special Content-* requirements, defining the stored Content-* properties by URL rather than PUT headers.. Regards Henrik
Received on Wednesday, 6 May 2009 08:42:21 UTC