RE: Draft TAG finding available: Client handling of MIME headers

> 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