Last modified: 2012-04-16 09:15:45 UTC
Add support for the use of the 100 (Continue) Status header for POSTS per HTTP/1.1 W3C RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
Unfortunately I don't think PHP exposes a way to handle this. Quick summary of how it's intended to work: - client sends *headers only* for an HTTP POST request, including the 'Expect: 100-continue" header - client waits for a bit while... - server processes the headers for the incoming request and sees the 'Expect' header - server performs some (unspecified, app-specific) sort of validation of the request based on the available headers, knowing that it does not yet have the actual POST request body - server sends either an HTTP 100 Continue response or an HTTP 417 Expectation Failed response as a signal to the client - client wakes back up and, if it got the 100, sends the actual request body. - server processes the complete request, which now has both headers *and* a request body. - server sends response body back to client - client is done! The problem is that we would need to hook in *between* the processing of the headers and the return of the 100 or 417 status... but our PHP code isn't running yet, because we don't get initialized until the entire request body has been read and processed. I haven't tested for sure, but most likely either the header gets ignored, or Apache/PHP send back a 100 under more or less all circumstances. Now, even if we did have a way to process it, I'm not sure how useful it would be. Validation of login state, user permissions, and data validity will usually be dependent on parameters that are typically sent in the POST body, so they wouldn't be available yet before the request body has come through.
(In reply to comment #1) > Now, even if we did have a way to process it, I'm not sure how useful it would > be. Validation of login state, user permissions, and data validity will usually > be dependent on parameters that are typically sent in the POST body, so they > wouldn't be available yet before the request body has come through. You're exactly right, it would be of almost zero use. If PHP/Apache currently send an unconditional 100 back, this bug is WONTFIX. If PHP/Apache somehow misbehave and break clients expecting proper behavior according to spec, that's a bug, but that'd be PHP's or Apache's fault, not ours. Could the reporter clarify which one they meant (i.e. is this a feature request or a bug)?
A feature request...currently it responds with a 417 (Expectation Failed) as per protocol...so this should be marked as WONTFIX. @Brion Vibber...thanks for explaining why it wouldn't be of much use.
(In reply to comment #3) > A feature request...currently it responds with a 417 (Expectation Failed) as > per protocol...so this should be marked as WONTFIX. > Closing WONTFIX then.
