- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 6 May 2003 22:17:53 +0200
- To: "Roy T. Fielding" <fielding@apache.org>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: <www-tag@w3.org>
> From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Tuesday, May 06, 2003 10:08 PM > To: Julian Reschke > Cc: www-tag@w3.org > Subject: Re: Draft TAG finding available: Client handling of MIME > headers > > > > Let's assume that an HTTP user agent uses PUT to send an entitity body > > to an > > HTTP server, but neglects to provide a content-type header. What's the > > recommend server behaviour for subsequent GET requests to that > > resource? > > > > 1) do not send a content type header (server refuses to guess), > > > > 2a) guess content type based on "extension" (hmph...) or > > > > 2b) guess content type based on content (for instance after > > successfully > > parsing as HTML) > > > > 3) ...? > > > > > > Note that 2a) is what currently Apache/moddav does, and this really > > seems to > > be a very bad idea. > > It is what the owner of that URI-space has configured the server to do. > The reason it does that is to support a whole host of features beyond > webdav that should not be disabled just because one authoring interface > has no knowledge of them. You make that sound as if persisting type information supplied by a client is incompatible to what the server does today -- and I think this is not the case. Apache/moddav very well could continue to do what it does today, yet persist additional content type data that was sent by the client in it's DAV store. If a client PUTs a UTF-8 encoded XML document and properly declares both type and encoding, but a subsequent GET returns different (and wrong!) information this really smells like a bug, not a feature. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 6 May 2003 16:18:11 UTC