httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server/mpm/perchild perchild.c
Date Mon, 07 May 2001 22:55:05 GMT

> > > > Readbytes is only to be used by the filter that actually reads from the
> > > > network and the function that is requesting information.  The function
> > > > that is requesting information (i.e. the top of the filter stack),
> > > > should insert either 0 or a positive value.  0 means read one line of
> > > > input, a positive value means read no more than this amount from the
> > > > network.
> > > >
> > > > The filter that is reading from the network should insert the number of
> > > > bytes read.  All other filters should ignore this value.  That's why this
> > > > used to be a field in the conn_rec, but at the hack-a-thon, it was
> > > > decided that this should be a parameter instead.
> > > >
> > > > The whole reason for this field, is that it is impossible to determine
> > > > when one request is done and another begins without information that is
> > > > stored in the request_rec.
> > >
> > > Umm. I don't see how this will work with SSL - the number of bytes read
> > > at the network layer does not correspond to anything happening at the
> > > request layer...
> > >
> > > Seems to me that this is being used to do something rather magical and
> > > protocol dependent...
> >
> > Does SSL use a content-length?  How does SSL know when the entire request
> > has been read?
>
> Why would SSL care? The point is the content length happens at a layer
> above SSL. It's like asking "how does TCP/IP know when the entire
> request has been read?" - it doesn't.
>
> I presume that having the SSL filter fill in the decrypted length
> instead of the stuff read at the network layer would work for this case,
> but that doesn't really answer the question.

Wait, my bad.  Rewind, and start over.  The problem was imprecise english,
and my assumption that I was saying what I meant.

I said that the filter that should modify the variable was the one that
read from the network.  That is the case for HTTP, but not for HTTPS.  In
reality, the filter that should modify that value is the filter that
understands the protocol.  If I understand the SSL filter logic, then that
filter has to be lower in the stack then the HTTP_FILTER.  That is because
the HTTP_FILTER only deals with decrypted data.

In this case, the HTTP_FILTER is the one that understands the protocol, so
it is the only filter that should modify that value.  This way, the SSL
filter just returns what it has read and decrypted to the HTTP_FILTER, and
it lets that filter handle determining where we are in the HTTP
processing.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message