Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: TOKILEY@aol.com
Message-ID: <31.1b23df4b.28e03549@aol.com>
Date: Mon, 24 Sep 2001 03:05:45 EDT
Subject: Re: [PATCH] Take 2 of the http filter rewrite
To: dev@httpd.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


In a message dated 01-09-24 00:37:41 EDT, Justin wrote...

> > The only real question is what happens when readbytes is -1 - a
>  > higher-level filter explicitly asks for everything.  We'd then do a
>  > blocking read for the entire socket until it is exhausted.  I think
>  > the current code would have problems with it as well anyway.  I'm not
>  > really sure what we can do here.  Thoughts?  -- justin
>  
>  The current code doesn't have problems with this, because we rely on
>  the fact that the HTTP_IN filter understands HTTP.  It knows when the 
>  request is done. Anything else is invalid.
>  
>  Ryan

Correct... if a 'higher level filter' asks for 'everything' then it's all
relative to the nature of the filter itself and the 'direction' of
the data.

If it is a 'request' level filter then the only thing 'give me everything'
can/should ever mean is 'everything associated with this request
but not the next one'.

If the 'direction' is 'from client' then it doesn't even matter if
Keep-Alive or Pipelining is used... the meaning of 'everything'
becomes relative. Might mean 'It's a POST so give me all the
data that's coming for this request' or 'It's not a POST but I
didn't get the EOH blank line yet'.

No one can expect a 'read' of an HTTP client to hang out and
wait until a client socket 'closes' to be sure you have 'everything'
because when a client socket closes the conversation is OVER.

What someone (inside a filter) is 'asking' for and 'what they get'
is always going to be relative to where you are in the HTTP
conversation FSP. The HTTP request/response format is really
nothing more than a Finite State Processor where only certain
things can happen after certain other things. There has to be
SOME input/output filter at the connection level that always
knows what 'state' the HTTP FSP is in.

> > Justin wrote...
> > We'd then do a blocking read for the entire socket until it is exhausted.

You simply can't. 'exhausted' is totally relative to what HTTP 'state' you
are in. See above. If 'exhausted' when reading client means 'when
a timeout takes place or socket closes' then the conversation is already
completely OVER.

Yours...
Kevin Kiley