W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 18 Feb 2005 08:38:02 -0800
Message-Id: <fbe0d45ea990814666b5ea12c4c6ea81@osafoundation.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>, Helge Hess <helge.hess@opengroupware.org>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

Yes, I agree there would need to be some added definition for it to 
work clearly and interoperably.  But I can't see how the mechanism 
itself is flawed other than being incompletely described and 
unimplemented :)

Lisa

On Feb 18, 2005, at 12:26 AM, Stefan Eissing wrote:

>
> I think it is also not clear if its a hop-to-hop or end-to-end header. 
> So chances of getting it working in an uncontrolled environment are 
> not good.
>
> //Stefan
>
> Am 17.02.2005 um 22:28 schrieb Julian Reschke:
>
>>
>> Helge Hess wrote:
>>> On 17. Feb 2005, at 22:04 Uhr, Jim Whitehead wrote:
>>>> 1) One problem clients currently encounter with PUT is determining 
>>>> whether
>>>> they have permission to write to a specific location. At present, a 
>>>> client
>>>> must submit a PUT (or ADDMEMBER) with the entire entity body, then 
>>>> wait for
>>>> the response, or the authentication challenge.
>>> Isn't that already solved with Expect: 100-continue?
>>> http://zvon.org/tmRFC/RFC2616/Output/chapter14.html#sub20
>>
>> Sort of. The problem is that it's extremely hard to implement using 
>> the Java servlet API (but that's "just" an implementation issue...).
>>
>> Best regards, Julian
>>
>> -- 
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>
>
>
Received on Friday, 18 February 2005 16:38:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:07 GMT