RE: IE5 bug, was... RE: MKCOL with entity request body

>>> The entire intent of this requirement was extensibility.  We wanted to
>>> ensure that implementors wouldn't add code that rejected a MKCOL
>>> immediately
>>> if it had a request body, since this would make future extension
>>> of MKCOL
>>> impossible.
>>
>> In that case IE5 needs to fix this. :-)  IE5 closes the
>> connection before even
>> reading the body.  It apparently is not prepared to accept a multi-status
>> response.
>
> I had been thinking this was a server-side extensibility issue.  I don't
> think it's unreasonable for a client which submits a MKCOL without a request
> body to not accept a 207 response, when the spec. states that a 201
> (Created) is returned.

> So, if a client submits a MKCOL without request body, it really only needs
> to expect a 201 (Created) as a response code (although it should do the
> right thing and treat all other 2xx responses as a 200, and a good
> implementation would also read the body of a 207).
>
> If a client submits a MKCOL with request body, it should expect either a 201
> or a 207 -- both are legitimate responses.

I'd like to make a similar observation for IE5's processing of MOVE (and COPY?).
It would be good if it also supported 207 MultiStatus and checked the body for
status.

This does lead me to another question though.  Is it acceptable to return a
single 2xx return codes within a MultiStatus?  My reading of the spec suggests
it is.


More shortly....

J.

Received on Thursday, 17 June 1999 16:10:43 UTC