On Tue, Oct 02, 2001 at 12:11:18AM -0700, Justin Erenkrantz wrote:
>...
> I would say that there should be a response object that a particular
Careful with the notion of a response object. As you may have guessed, I'm
not taking kindly to request/response object access from within the filter
stacks. :-)
That said, we are probably going to need some kind of notion of a request
and response object. At a minimum, a response has to be able to say "I am
associated with <that> request."
But these objects could also be part of a higher level layer:
REQUEST --> OUTPUT STACK -->
NETWORK
RESPONSE <-- INPUT STACK <--
IOW, they aren't constructed/handled except for above the I/O filter stacks.
I believe that the network layer is going to have some kind of queue of
requests that it maintains. As each request is sent down the pipe, it is
appended to the queue. When a response comes back, the associated request is
peeled off the queue.
Note that we could send a (metadata) bucket up the input stack that says
"this is the response for <foo>." Not sure how we'd identify the request,
though. Possibly by some kind of numeric id which is sent in a bucket down
the output stack.
> filter should read the headers and store them in a hash and then
> the headers (as a specific bucket themselves - each header is a
> bucket itself) can be passed down the chain like any other bucket
> after it has been recorded. I don't think it is necessary for
> all filters to record each header individually
Euh... not sure why they would?
When I referred to filters storing headers, I was referring to the case
where a filter needs to look for header X to trigger its response. When it
finds that, it modifies a couple headers and then processes the body in some
fashion. It needs to delay those (to-be-modified) headers from going down
the stack before it gets a chance to change them.
> (you have a response
> object to deal with storing it - actually, it should run at the end
> of the HTTP Header chain - so that filters could modify the headers
> as they are passed down from the HTTP protocol reader - then the
> filter that records the header consumes it and doesn't pass it down
> anymore).
Yes. (per my diagram above)
> The bucket for headers is simply a string with a position/pointer
> of the : marked. At least, that's how I see it.
Possibly, but that form makes it hard to extract the name (no null term).
> It is fairly
> straightforward to get the value and name out of that.
You may have to copy the name so that you can stick a null term on it.
> Reading
> the bucket via bucket_read should just return the string. But,
> if you know it is a header bucket, you can call the special ops
> to get the name/value pairs. MIME folding makes things a bit
> interesting though. Not sure exactly how that'd work out though.
> Feasible. This is what makes ap_getline in httpd such an oddball
> to replace because it cheats and looks ahead to make sure that the
> line isn't folded. Not typically ideal, but necessary given the HTTP
> semantics. We may be even able to cheat and just expand all of the
> folding - the HTTP input filter (i.e. reading from the socket) would
> just handle the MIME folding and send only key-value pairs down. If
> it is folded or has multiple values, each value is sent separately
> down the filter stack. It'd be easy to work with it that way, I
> think. When the HTTP input-filter has read EOH (i.e. two CRLFs),
> it sends that down and now we deal with content-only at that point
> (well, excepting trailers w.r.t. chunked-encoding). -- justin
I'd say the HTTP_IN filter does *all* the processing for the headers before
delivering them up the stack. It would manage all parsing and folding.
Note that we read mime-style headers as the header of the HTTP response,
within multi-part bodies, and as trailers. IMO, a function to consume data
from a brigade and assemble a hash table would be nice for all of these.
(tough function, though, as it needs to be restartable if you run out of
input)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
