W3C home > Mailing lists > Public > www-tag@w3.org > May 2003

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 7 May 2003 01:52:08 +0200
To: <www-tag@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEABHEAA.julian.reschke@gmx.de>

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
> Julian Reschke
> Sent: Tuesday, May 06, 2003 10:18 PM
> To: Roy T. Fielding; Julian Reschke
> Cc: www-tag@w3.org
> Subject: 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.

Note to all -- I got myself confused because I was thinking about two
*separate* issues at the same time.

Issue #1: clients that do PUT without passing a content type -- what's the
recommended server behaviour upon subsequent GETs? If the server *does*
guess, and guesses wrong, the client ends up with a wrong content type --
wouldn't be preferable then not to send a content type at all (in which case
the client issuing the GET would need to guess)?

Issue #2: if a client *does* send the content type with PUT, is a server
allowed to override that (that's what currently happens with
Apache/moddav).?

Sorry for the confusion,

Julian



--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 6 May 2003 19:52:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:58 UTC