At 4:22 PM -0800 3/2/02, Justin Erenkrantz wrote:
>On Sat, Mar 02, 2002 at 02:30:34PM -0800, Ryan Bloom wrote:
>> I'm sorry, but this is BOGUS! I want to see a 2.0 release, but adding
>> code that is wrong just so that we can get a GA release is NOT the way
>> to go about doing that. The whole p
On Sat, Mar 02, 2002 at 02:30:34PM -0800, Ryan Bloom wrote:
> I'm sorry, but this is BOGUS! I want to see a 2.0 release, but adding
> code that is wrong just so that we can get a GA release is NOT the way
> to go about doing that. The whole point of Open Source is that we don't
> have to cut cor
At 04:26 PM 3/2/2002, you wrote:
>Right. I'm content for just trying to get something to work now
>and readdress this when we open 2.1. I think that there can be
>multiple independent request_rec's created for one connection.
Yes - we won't revisit the idea of splitting req_rec into proto_rec
> On Sat, Mar 02, 2002 at 11:25:33AM -0800, Ryan Bloom wrote:
> > My opinion is that a request is the time from when a user sends the
GET
> > line to the time that the response is sent back. Justin (please
correct
> > me if I am wrong) believes that the request is the lifetime of the
> > request_
On Sat, Mar 02, 2002 at 11:25:33AM -0800, Ryan Bloom wrote:
> My opinion is that a request is the time from when a user sends the GET
> line to the time that the response is sent back. Justin (please correct
> me if I am wrong) believes that the request is the lifetime of the
> request_rec in the
> At 12:36 PM -0800 3/2/02, Ryan Bloom wrote:
> > > Ryan Bloom wrote:
> > > >
> >
> >We actually tried to add it a while ago, but it was vetoed because
HTTP
> >doesn't need it. The overhead could actually be minimal, because the
> >big stuff to move there is the protocol filters and the user/pass
At 12:36 PM -0800 3/2/02, Ryan Bloom wrote:
> > Ryan Bloom wrote:
> > >
>
>We actually tried to add it a while ago, but it was vetoed because HTTP
>doesn't need it. The overhead could actually be minimal, because the
>big stuff to move there is the protocol filters and the user/password
>informat
> Ryan Bloom wrote:
> >
> > We originally wrote the protocol filters to be connection based, but
> > that had some drawbacks that people were unwilling to live with, and
it
> > made writing input filters very complex. Today, the filters that
> > implement the protocol are request based.
>
> Gotc
Ryan Bloom wrote:
>
> We originally wrote the protocol filters to be connection based, but
> that had some drawbacks that people were unwilling to live with, and it
> made writing input filters very complex. Today, the filters that
> implement the protocol are request based.
Gotcha. I checked b
BTW, after reading this note again, this also solves another problem we
have. The filter type right now is AP_HTTP_HEADER_FTYPE, and there is a
comment that the name sucks. The correct name is AP_PROTOCOL_FTYPE,
which denotes exactly what we are trying to do with this filter type.
Ryan
> > Ju
> Justin Erenkrantz wrote:
> >
> > A protocol filter shouldn't survive successive
> > iterations of a "request"
>
> Even if in the same "connection"? That doesn't seem quite right to
me...
> I'm confused as well :/
We originally wrote the protocol filters to be connection based, but
that had som
Justin Erenkrantz wrote:
>
> A protocol filter shouldn't survive successive
> iterations of a "request"
Even if in the same "connection"? That doesn't seem quite right to me...
I'm confused as well :/
--
===
Jim Jagielsk
> On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote:
> > You are thinking of this wrong. Filters that are stored on
> > r->protocol_filters wouldn't survive a single request, they would be
> > required for the lifetime of the request. The idea is that anything
> > that lives in r->outpu
On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote:
> You are thinking of this wrong. Filters that are stored on
> r->protocol_filters wouldn't survive a single request, they would be
> required for the lifetime of the request. The idea is that anything
> that lives in r->output_filters
> On Fri, Mar 01, 2002 at 04:50:16PM -0800, Ryan Bloom wrote:
> > I don't understand how this is working. The original code from Will
> > came from a discussion that he and I had over the phone. My
question is
> > how were the protocol specific filters removed in this case?
> >
> > Oh, damn, the
On Fri, Mar 01, 2002 at 04:50:16PM -0800, Ryan Bloom wrote:
> I don't understand how this is working. The original code from Will
> came from a discussion that he and I had over the phone. My question is
> how were the protocol specific filters removed in this case?
>
> Oh, damn, the problem is
> On Fri, Mar 01, 2002 at 03:12:27PM -0600, William A. Rowe, Jr. wrote:
> > I believe the attached .patch file should resolve our issues with
the
> > subrequest
> > negotiation. Essentially, we want the sub request to build a new
filter
> > chain if
> > we plan on using the subrequest as a 'fast
On Fri, Mar 01, 2002 at 03:12:27PM -0600, William A. Rowe, Jr. wrote:
> I believe the attached .patch file should resolve our issues with the
> subrequest
> negotiation. Essentially, we want the sub request to build a new filter
> chain if
> we plan on using the subrequest as a 'fast internal red
I believe the attached .patch file should resolve our issues with the
subrequest
negotiation. Essentially, we want the sub request to build a new filter
chain if
we plan on using the subrequest as a 'fast internal redirect'.
This patch does just that, when we fast redirect, we replace the origin
19 matches
Mail list logo
