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

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
> Tim Bray
> Sent: Wednesday, May 07, 2003 8:59 PM
> To: Julian Reschke
> Cc: www-tag@w3.org
> Subject: Re: Draft TAG finding available: Client handling of MIME
> headers
>
>
>
> Julian Reschke wrote:
>
> > 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)?
>
> I think that in this case it's reasonable for the server to guess or to
> not guess based on the application needs.  I don't see an architectural
> issue.

OK,

issue #1b: if the client doesn't supply a content type (or if the server
isn't able or willing to persist the content type information supplied by
the client), and the server doesn't have a "best guess" (such as when the
"extension" is unknown), what behaviour is preferrable:

a) upon GET, send content type "application/octet-stream" or

b) upon GET, send no content type at all.

Note that in case b), a client would be allowed to guess itself (it may have
more information than the server!).

Scenario:

Client has a new HTTP-based application, let's call it myCal. Client PUTs
files with extension "mycf".

Server doesn't have a preference for the extension "mycf", and serves the
content as "application/octet-stream".

According to <http://www.w3.org/2001/tag/doc/mime-respect-20030505.html>:

---
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type
header field defining the media type of that body. If and only if the media
type is not given by a Content-Type field, the recipient MAY attempt to
guess the media type via inspection of its content and/or the name
extension(s) of the URI used to identify the resource. If the media type
remains unknown, the recipient SHOULD treat it as type
"application/octet-stream".
---

So now when the *same* client GETs the resource through a compliant user
agent, dispatching to his "mycf" application will fail, because it MUST
respect the content type sent by the server (saying octet-stream).

Proposals:

i) allow servers not to send a content-type in case they really don't know,
or alternatively

ii) allow user agents to ignore the content-type if they think it was
guessed (i.e., if it is "application/octet-stream").




Julian





> ...



--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 May 2003 03:47:35 UTC