RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, February 18, 2002 4:57 PM
> To: Webdav WG; Julian Reschke
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
> > > 2. When a client creates a resource without mime type, should
> > > the server make a guess or report application/octet-stream?
> >
> > It could, but I wouldn't recommend that. It may make sense to report a
> > *specific* content type (such as application/x-foobar), but reporting
> > "application/octet-stream" doesn't really help anybody.
> >
>
> I'm not sure this is workable.  You're right that defaulting to
> application/octet-stream doesn't help anybody, but it may hurt
> less.  When a
> client creates a resource without a MIME type, then a client asks for the
> resource using GET, the server must put some value in the Content-Type
> header.  Since "getcontenttype" is defined as the type that would be

No, it doesn't (as far as I can tell). RFC2616 says that the Content-Type
SHOULD be present, but then goes on saying what a recipient is allowed to do
when it's absent. So if you PUT without content type, cou can't *expect*
that the magically will invent one.

> returned in the Content-Type header were the client to do a GET
> request, it
> must have the same value.
>
> This isn't a DAV problem only -- any Web server might have the
> same problem.

Right, that's why RFC2616 is relevant.

Received on Tuesday, 19 February 2002 02:44:07 UTC