Subject: IPP> Processing Algorithm

From: [email-masked] (Zhi-Hong Huang)
Date: Thu, 20 Nov 1997 16:46:12 -0800

I am a bit confused reading Session 15.3 in the model document.
It says that processing continues step by step until a reject
the request is encountered or the last step is reached. Does
it mean that with HTTP 1.1, the client has to send and wait at
each step for the server response?

Since client may POST several IPP requests on a single HTTP 1.1
connection, if the server replys before consuming all the data
the client sends, it would be difficult for the server to locate
where the next message starts. There would be no problem if the
client closes connection after each message. Is this a requirement?

Zhi-Hong Huang
Zenographics, Inc.

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Nov 1997 09:47:39 -0500

>>>>> "ZH" == Zhi-Hong Huang <[email-masked]> writes:

ZH> Since client may POST several IPP requests on a single HTTP 1.1
ZH> connection, if the server replys before consuming all the data
ZH> the client sends, it would be difficult for the server to locate
ZH> where the next message starts.

  I'm not entirely sure that I'm addressing the right concern here,
  but... an HTTP/1.1 server can detect the end of an entity body in
  any of three ways: a Content-Length header, Transfer-Encoding:
  chunked, or a Multipart encoding that is self-descriptive.

  It is true that an HTTP client using persistent connections (either
  1.1-style or the Netscape Keep-Alive style) must keep track of the
  order of requests, and the server must preserve that order in
  sending responses as there is no transaction identifier.

  Did that answer your question?

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

---

From: Jay Martin <[email-masked]>
Date: Fri, 21 Nov 1997 10:21:41 -0500

I think Zhi-Hong has raised a very valid concern here, one that we
should address in a clean and unambiguous manner within IPP.

If IPP allows multiple posts (requests) in which the client is
expecting to receive multiple responses, then IPP should be
clearly defined to do one (and only one) of the following:

  a) Ensure the order of responses is *exactly* in the same
     order as the requests, or

  b) Define and force mandatory usage of a client-specified
     transaction id (included as part of a request) that the
     server attaches to all responses.  The transaction id
     would be considered completely opaque to the server (ie,
     no semantic meaning whatsoever).

If we wish to provide maximum performance potential, then the
second choice would be the second (b) option.  Adding such a
transaction id wouldn't add that much "baggage" to the protocol.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

Subject: Re: IPP> Processing Algorithm
From: "Scott Lawrence" <[email-masked]>
To: [email-masked] (Zhi-Hong Huang)
Cc: [email-masked]
Date: Fri, 21 Nov 1997 09:47:39 -0500

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Nov 1997 10:55:47 -0500

>>>>> "JM" == Jay Martin <[email-masked]> writes:

JM> If IPP allows multiple posts (requests) in which the client is
JM> expecting to receive multiple responses, then IPP should be
JM> clearly defined to do one (and only one) of the following:

JM>   a) Ensure the order of responses is *exactly* in the same
JM>      order as the requests, or

  You don't have any other alternative if you are running over HTTP.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 21 Nov 1997 08:43:50 PST

The HTTP-NG protocol design group is presupposing that while
application software wants request/response matching, it is
the function of lower level software to supply it.

IPP is an important target for HTTP-NG.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: [email-masked] (Zhi-Hong Huang)
Date: Fri, 21 Nov 1997 09:03:41 -0800

>   Did that answer your question?

That should be fine if the server is required to consume
all the client's data whether or not it decides to reject
a request.
One solution could be as follow: If the server rejects a
request and will not further receive data from the client,
it will close the connection.

Zhi-Hong Huang
Zenographics, Inc.

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Nov 1997 12:29:03 -0500

SL> Scott Lawrence wrote:

SL> an HTTP/1.1 server can detect the end of an entity body in
SL> any of three ways: a Content-Length header, Transfer-Encoding:
SL> chunked, or a Multipart encoding that is self-descriptive.

>>>>> "ZH" == Zhi-Hong Huang <[email-masked]> writes:

ZH> That should be fine if the server is required to consume
ZH> all the client's data whether or not it decides to reject
ZH> a request.
ZH> One solution could be as follow: If the server rejects a
ZH> request and will not further receive data from the client,
ZH> it will close the connection.

  Either party in an HTTP connection is free to close it at any time;
  in practice this can lead to cases in which the results of some
  requests may be unknown (because of interaction with TCP resets).

  The bad case is when the server closes the TCP connection after
  sending an error response based on the request headers, the TCP
  close causes the server to send an RST in response to the incoming
  body, and the servers response gets lost when the RST causes the
  client to flush received data without delivering it.  [I realize
  that was a little confusing. ]

  The HTTP '100 Continue' status was intended to help with this
  situation; the client would send the headers for a request with a
  body, then wait for a '100 Continue' status before sending the body
  (or an error, in which case the body is not sent at all).  This
  allows the server to send an error response when a problem is
  detectable strictly using the headers (such as lack of a valid
  'Authorization' header field, or an invalid URL), before the TCP
  connection gets the body in it.  It was decided in the HTTP/1.1
  standard not to require that the client _always_ wait for the '100
  Continue' response before transmitting the body - instead, the
  client MAY indicate that it will wait for a '100 Continue' response
  before transmitting the body by including an 'Expect: 100-continue'
  header in the request.  It might be a good idea (IMHO) for IPP with
  its potentially large POST operations to require this behaviour.

  I would provide a pointer to the I-D for this, but a new one should
  be out today with different section numbers, so I'll wait a bit.

---

From: Tom Hastings <[email-masked]>
Date: Fri, 21 Nov 1997 09:44:42 PST

>it will close the connection.

We have agreed that servers SHOULD issue a reject response to a client 
as soon as the server knows that it is going to reject the create request
because of Operation or Job Template attributes supplied up front by the 
client, rather than waiting until the client has sent all of the document 
data which follows and which could be large.  

There seems to be two ways to avoid sending all of the document data
when the server rejects the create request:

1. The client gets the response and sees the reject, so the client stops
sending the rest of the data.

2. The server sends the reject response and then close the connection,
forcing the client to stop sending the rest of the document data.

Scheme 1 would allow the connection to stay open.

Are both schemes feasible with HTTP/1.1?

Can an HTTP/1.1 client accept a response while sending a (long) request
on the same connection?

Tom

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Nov 1997 12:56:12 -0500

>>>>> "TH" == Tom Hastings <[email-masked]> writes:

TH> We have agreed that servers SHOULD issue a reject response to a client
TH> as soon as the server knows that it is going to reject the create request
TH> because of Operation or Job Template attributes supplied up front by the
TH> client, rather than waiting until the client has sent all of the document
TH> data which follows and which could be large.

TH> There seems to be two ways to avoid sending all of the document data
TH> when the server rejects the create request:

TH> 1. The client gets the response and sees the reject, so the client stops
TH> sending the rest of the data.

  If the HTTP request headers included a Content-Length, then the only
  way for the client to abort the request is to close the TCP
  connection.

  If the HTTP request is sent with 'Transfer-Encoding: chunked'
  instead, and the server sends a reject, then the client can abort a
  body already started by sending a zero-length chunk.  Having
  rejected the HTTP method, the server will just discard any body.
  The use of the chunked body with POST or PUT allows the server to
  keep the connection open in this case.

TH> 2. The server sends the reject response and then close the connection,
TH> forcing the client to stop sending the rest of the document data.

  Leads to the bad case I described in my last note - the client IPP
  layer may never see the error response.

TH> Can an HTTP/1.1 client accept a response while sending a (long) request
TH> on the same connection?

  Implementation detail, but I would suggest that it is a good idea.