Posted by Andy Hassall on 10/07/97 11:56

On 23 Aug 2006 13:17:34 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:

>Andy Hassall wrote:
>> On 22 Aug 2006 20:38:44 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
>>
>> >I don't think the HTTP protocol specs mandates that a response can only
>> >be sent after the request body has been fully received
>>
>> Isn't it implied by HTTP 1.1 sec 6:
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
>> "6 Response
>>
>> After receiving and interpreting a request message, a server responds with an
>> HTTP response message. "
>>
>> The key being "After"?
>
>But the existence of status code 100 implies a interim response can be
>sent. Look at 8.2.3:
>
>The purpose of the 100 (Continue) status (see section 10.1.1) is to
>allow a client that is sending a request message with a request body to
>determine if the origin server is willing to accept the request (based
>on the request headers) before the client sends the request body. In
>some cases, it might either be inappropriate or highly inefficient for
>the client to send the body if the server will reject the message
>without looking at the body.
>
>[http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3]
>
>So the desired behavior is defined in the specs. I don't know if it's
>widely implemented though.

Ah! Interesting - thanks.

So PHP could - in theory - send the response back as a 417 and populate
$_FILES with a suitable error.

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Back to original message]