Subject: RE: IPP> Processing Algorithm

From: "Turner, Randy" <[email-masked]>
Date: Fri, 21 Nov 1997 10:12:49 -0800

We agreed that the server would immediately send back an
error response once it had determined an error condition. The
server would not wait until the client delivered all of the 
current request. I believe most TCP/IP API services allow
the client to detect input on a socket during successive
"send" calls...

Randy

> -----Original Message-----
> From:	Tom Hastings [SMTP:[email-masked]]
> Sent:	Friday, November 21, 1997 9:45 AM
> To:	[email-masked]; [email-masked]
> Subject:	Re: IPP> Processing Algorithm
> 
> At 09:03 11/21/1997 PST, Zhi-Hong Huang wrote:
> >Scott Lawrence wrote:
> >
> >>   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.
> >>
> >>   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.
> 
> 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
> 
> >
> >Zhi-Hong Huang
> >Zenographics, Inc.
> >
> >
> >