- From: Michael Sweet <msweet@apple.com>
- Date: Tue, 22 Jul 2014 08:32:53 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Zhong Yu <zhong.j.yu@gmail.com>, Greg Wilkins <gregw@intalio.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
and for example CUPS will first send a 101 (if necessary) to force TLS encryption of the connection and then a 401 if authorization is required. On Jul 22, 2014, at 6:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-07-22 08:16, Zhong Yu wrote: >> On Mon, Jul 21, 2014 at 11:03 PM, Greg Wilkins <gregw@intalio.com> wrote: >>> >>> On 22 July 2014 13:36, Zhong Yu <zhong.j.yu@gmail.com> wrote: >>>> >>>> What is the end-to-end semantics though? As far as the application is >>>> concerned, the request-response cycle has the same semantics whether >>>> or not 100-continue is exchanged under the hood. >>> >>> >>> The semantic that the client application is seeking is confirmation from the >>> origin server that it has inspected the headers and has consented for the >>> body to be sent. >> >> This is a new way of interpreting it, but it's probably not the >> original intent, and it's not supported by the text of the spec. If a >> server does not respond with 100, it doesn't mean the body is >> forbidden to be sent; the client can always send the body regardless >> of server response(s). >> .... > > Instead of sending the 100, the server can immediately send a 4xx error code. > > Best regards, Julian > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 22 July 2014 12:33:26 UTC