httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 02:14:44 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, October 12, 2000 7:33 PM
>
> > Caveat: we may need to distinguish APR_EOF -- between 
> "socket closed" and
> > "end of this request" ... I haven't thought about that part yet.
> 
> This is incorrect.  There is no such thing as EOF at end of
> request.  There is only an EOF when the connection closes.  There is no
> way for low level filters to know when they have hit the end of a
> request.  If that were possible most of this discussion would be moot.

There are four cases here by HTTP:

  no body: top socket input handler returns APR_EOF

  request-length: The answer is ... there is none at all, Greg is right
  on here.  The top socket input handler uses that length for gospel, 
  and will only pass on that many bytes.  When it has read all the 
  bytes, it returns APR_EOF.  But since each input filter could warp
  this number, we should just rename (not kill) it - client-sent-length
  or something on those lines.  It means nothing to the handler by the
  time input filters have warped it.

  chunked input: Same answer, top socket grabs chunks and passes them
  down till it gets the killer 0 chunk.  Very same issue, but here not
  even the top socket input handler could know what the total length
  may be.

  byterange: Is really an output filter (huh?) - we should filter the
  output stream (sorted, if we are allowed???) and throw away all but the
  needed bytes.

So, you suggest, we can optimize byterange, chunked input, and even req-len.
That's fine, then they are optimizations with tighter integration to the
flow.  Once we mix multiple input and output filters, this is the only way
I can see the thing working.  What about input filters/handlers that must
have the entire request-length in advance?  Perhaps we will have to cache
anyway if the input is chunked, throw it into a pipe and suck it back out?
I don't have a good answer to this last issue

I do know I don't want us to expect every app will accept every possible
http input mechanism.  Sorry I have not caught every word that has passed
on this topic, so if I'm out if it, I appologize.  I've pretty much left
this debate to the debate team, and plan to leave it that way.  I'd just
hate to see us hit a critical roadblock so close to rolling alpha-8 with
filtering.

> There is one solution I can think of for how to do this, but it is
> completely wrong and ugly and it makes absolutely no sense, 
> so if we ever
> tried to implement it I would veto it because it is just 
> wrong.  The idea
> is that on the first call down to http_filter we pass the
> content-length.  On subsequent calls, we just read until we 
> have read that
> much data, ignoring all other values of content-length that are passed
> down.  As I said this is just wrong.
> 
> As for why lower level filter can't know about the end of a 
> request, it
> has to do with the protocol.  There are two basic ways to 
> signal the end
> of a request body (I am ignoring multi-part/byteranges for now).  The
> first is to have a content-length in the request headers.  
> The second is
> to use chunked encoding.  Both of these things can only be 
> determined by
> looking at the request_rec.  However, the http_filter is a connection
> based filter, so it doesn't have access to a request_rec, therefore it
> doesn't have access to the headers.  This means that the 
> filter needs to
> be told how much data there is going to be.
> 
> > > What else does this mean?  It means that all of a sudden
> > > ap_get_client_block can actually receive more data from 
> the filters than
> > > it asked for.
> > 
> > Nope. This would still be restricted to what 
> ap_get_client_block() asked
> > for, from the top input filter. *That* filter may need to 
> do some set-aside,
> > but that isn't get_client_block's concern.
> 
> See above.  It isn't possible.
> 
> > > I dislike this, and there is a big part of me that thinks 
> we are violating
> > > the HTTP protocol by allowing filters to expand the body data like
> > > this.  The other thing that needs to be noted, is that if 
> we change the
> > > content-length, then that information also needs to be 
> changed in the
> > > request_rec.
> > 
> > 1) we aren't violating HTTP. it was designed for this kind 
> of expansion.
> > 
> > 2) don't put content-length into the request_rec. that is a 
> private matter
> >    for the chunk_filter, I believe. (not sure who's 
> responsible if the chunk
> >    filter isn't installed; but I know that we should not be 
> changing the
> >    value sitting in the request_rec (nobody should examine 
> that value!).
> 
> This won't work.  It looks like the chunking code in 
> ap_get_client_block
> is currently setting the Content-Length, so the chunk_filter 
> will need to
> set that correctly.  But that also tells me that there is a 
> reason we do
> that.  If nobody inside Apache cared about the 
> Content-Length, then the
> chunk code wouldn't need to set it.  A quick grep shows 
> mod_dav getting
> the value, but since you know mod_dav 1000 x better than me, 
> I'll assume
> you know why, and you won't care if it is set incorrectly.
> 
> If it does need to be set correctly, than ap_get_client_block 
> needs to set
> it to the new length after the transformations.
> 
> Ryan
> 
> ______________________________________________________________
> _________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
> 
> 

Mime
View raw message