RE: iCal

> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Thursday, September 12, 2002 7:43 PM
> To: Julian Reschke; uri@w3.org
> Subject: Re: iCal
>
>
> I think they're using the scheme for dispatch, because they can't rely on
> the media type being properly set, and/or they're lazy.
>
> This probably stems from the media type in a PUT being ignored; I'm not a
> WebDAV expert, but my testing with mod_put on Apache indicates that the
> media type of the PUT isn't used as metadata in subsequent GETs.

I'd consider this a shortcoming of moddav -- it surely could persist the
content type that was sent. "Our" (actually SAP's) WebDAV server does that,
just like the content language when specified in the PUT request.

Of course inventing a new URI scheme just to workaround a specific
shortcoming somewhere else is an extremely bad idea.

> It seems pretty clear cut in 2616 (section 9.6):
>
>  [[[ The PUT method requests that the enclosed entity be stored under the
> supplied Request-URI.]]]
>
> Note that it's "entity," not just "entity-body."
>
> [[[ The recipient of the entity MUST NOT ignore any Content-* (e.g.
> Content-Range) headers that it does not understand or implement and MUST
> return a 501 (Not Implemented) response in such cases.]]]
>
> [[[ Unless otherwise specified for a particular entity-header, the
> entity-headers in the PUT request SHOULD be applied to the resource
> created or modified by the PUT.]]]
>
> Anyone know of WebDAV (or plain PUT) implementations that correctly
> implement this? I suspect it isn't widely implemented, because most Web
> servers use filename extension rather than separate, per-resource metadata
> to determine media type.

The SAP Enterprise Portal WebDAV connector does this. If you're interested
in trying it, email me and I'll send you a test account on our server.

Julian

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

Received on Thursday, 12 September 2002 13:56:45 UTC