Re: 1xx Clarification

SDL> The most frequent case for our implementation at least will, I suspect,
SDL> be when the server has configured different realms for serving and
SDL> submitting a form.  This turns out to be a common situation in an
SDL> embedded system because it saves memory and simplifies interface design;
SDL> the same page is used to display current configuration information and to
SDL> change it, but the authentication required is different.

DK> Did you answer some other question?  It sounds like you're talking about
DK> Basic Authentication, not PUT/POST and 1xx responses.

  Sorry - brevity can be overdone.

  I was addressing the normal circumstances under which it would be
  good for a client to have waited before sending the message body:

        Client                               Server
          |                                    |
       >1 |-> GET /form.html HTTP/1.1 -------->|
          |                                    |
          |<------------- HTTP/1.1 200 Ok <----|
          |                                    |
          |                                    |
       >2 |-> POST /form.html HTTP/1.1 ------->|
          |        (no authorization)          |
          |                                    |
          |<---- HTTP/1.1 401 Unauthorized <---|
          |                                    |
          |                                    |
       >3 |-> POST /form.html HTTP/1.1 ------->|
          |        (with authorization)        |
          |                                    |
          |<------- HTTP/1.1 100 Continue <----|
          |                                    |
          |-> (form data) -------------------->|
          |                                    |
          |<------------- HTTP/1.1 200 Ok <----|
          |                                    |

  Request 1 is sent for a resource which contains a form, but which is
  not protected by any realm.  The resource is returned, and the
  client has the opportunity to note that the server is 1.1.

  Request 2 is sent to post the form, but submission of the form is
  protected by some realm, so this request is rejected.  The server
  can determine this before seeing the request body.

  Request 3 is the retry of 2 with authorization information; after
  the headers are received, the server returns the 100 Continue to
  indicate to the client that it is ok to proceed with the request
  body.

  If the client had sent the form data immediately with Request 2, it
  would have been just discarded by the server - a waste of time and
  bandwidth.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Tuesday, 22 April 1997 15:18:48 UTC