On Sun, Mar 03, 2002 at 06:04:08AM -, [EMAIL PROTECTED] wrote:
> rbb 02/03/02 22:04:08
>
> Modified:.STATUS
>include util_filter.h
>server util_filter.c
> Log:
> This finishes the mod_dir/mod_negotiation bug. This final part of the
It looks like this part of the patch wasn't as hard as I thought it
would be. I should have it committed in the next half-hour. The patch
is written, but I wanted to test some other stuff before I commit it.
Ryan
--
Ryan Bloom [EMAIL
On Sat, 2 Mar 2002, Ryan Bloom wrote:
> > > [EMAIL PROTECTED] wrote:
> > > Perhaps the logging module should be split up in the same way, with
> > > mod_log handling the hooks, and mod_log_disk handling logging direct
> to
> > > disk, mod_log_sql handling direct to database, etc.
> > Wouldn't jus
No, I think I have it, we are just making a lot of assumptions in this
code that we shouldn't make, and I am supposed to be doing real work.
But hey, sleep is overrated anyway. :-)
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St.
Ryan Bloom wrote:
>
> This might take some time to untangle, and the code is likely to change
> a lot in the interim. :-(
>
I have some cycles tomorrow if you'd like an extra pair of hands
or want to offload some of the stuff.
--
=
I don't know if anybody has realized this yet, but I am adding the
protocol output filter pointer in the request_rec, and what should have
been a very simple job is going to be huge now, because add_any_filter
is totally wrong. The problem is that we don't ever check which filter
list we are add
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 01:08:52PM -, [EMAIL PROTECTED] wrote:
> minfrin 02/03/02 05:08:52
>
> Modified:src CHANGES
>src/modules/proxy proxy_http.c
> Log:
> No idea why an HTTP/1.1 proxy would send an HTTP/1.0 request
> to a remote server by default.
The
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
I disagree entirely. You should be -able- to do so, without being forced
to do so.
The simple fix is not to define the default content type in the root of
the directive. However, there seems no 'trivial' way to do so,
unless would accomplish this.
If we don't support a 'none' option to the d
> > [EMAIL PROTECTED] wrote:
> >
> > > Though I one 100% agree with the stance that a proper web server
> should..
> > > well.. serve pages - It sure would be nice if we could have a
logging
> > > subsystem in apache 2.1 or higher which took care of some of the
> harder
> > > things for us module/
Watch out on the s. They are only allowed under
or and should each be in a separate tag set, without
the words "see also" as in:
Log Files
Environment Variables
Which will be presented something like:
See also:
Log Files
Environment Variables
Sorry this isn't well documented. You're do
On Sat, 2 Mar 2002, Bill Stoddard wrote:
> Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of
> these problems?
+1 - with perhaps something like an 'always pass through'. I.e. even if an
module provides an 'OK' it continues just as a 'DECLINE' so that certain
major failures c
On Sat, 2 Mar 2002, Sander Striker wrote:
> > In a recent patch to mod_proxy, a static buffer used to store data read
> > from backend before it was given to frontend was changed to be allocated
> > dynamically from a pool like so:
> >
> > +/* allocate a buffer to store the bytes in */
> > +
On Fri, 1 Mar 2002, Graham Leggett wrote:
> Igor Sysoev wrote:
>
> > mod_proxy can not do many things that mod_accel can. Some of
> > them can be easy implemented, some not.
>
> Keep in mind that mod_proxy is exactly that - a proxy. It does not try
> to duplicate functionality that is performed
> [EMAIL PROTECTED] wrote:
>
> > Though I one 100% agree with the stance that a proper web server should..
> > well.. serve pages - It sure would be nice if we could have a logging
> > subsystem in apache 2.1 or higher which took care of some of the harder
> > things for us module/appserver devel
> >
> > *) get backend response as soon as possible even it's very big.
> >mod_accel uses temporary file for buffering backend response if
> >reponse can not fill in mod_accel configurable buffer.
>
> This kind of thing is fixed in v2.0 in mod_cache. It is too big an
> architecture change
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
"Rief, Jacob" wrote:
> It seems as if the cookie-merging code in proxy_httpd.c version>=1.83
> introduced a new bug.
> In one special case a single valued cookie is splitted into
> two cookies with garbage values (see below)
This is correct behavior - the comma character is the header separator
Sander Striker wrote:
> Can you point me to the original post? I'd like to see the context.
> Specifically which pool is being used.
The original was .
Regards,
Graham
--
-
[EMAIL PROTECTED]"There's a moon
> -Original Message-
> From: minfrin [mailto:minfrin]On Behalf Of Graham Leggett
> Sent: 01 March 2002 05:24
> To: Apache Developers List
> Subject: Allocating a buffer efficiently...?
>
>
> Hi all,
>
> In a recent patch to mod_proxy, a static buffer used to store data read
> from bac
Hi all,
Recently someone noted that certain parts of Ebay didn't work via
mod_proxy. This was because the pages in question had no content-type
header, and Apache was adding a default header "text/plain", which
caused browsers to display the source of the page.
The resulting discussion said that
Hi all,
In a recent patch to mod_proxy, a static buffer used to store data read
from backend before it was given to frontend was changed to be allocated
dynamically from a pool like so:
+/* allocate a buffer to store the bytes in */
+/* make sure it is at least IOBUFSIZE, as recv_buffer_
Eli Marmor wrote:
> Then, integration with mod_proxy still needed, because the connection
> of mod_proxy with the backend server was still done directly, and not
> through the filtering infrastructure.
The v2.0 port has used the filtering infrastructure on the backend since
day one - however thi
ycheng wrote:
> Sorry to ask here, cause after try to read some rfc, I still
> can't tell whether this is a bug or a feature of mod_proxy.
>
> As I use mod_rewrite + mod_proxy by append a [P] after RewriteRule,
> I found that if the origional http request contain two
>
> "Set-Cookie"
>
> Heade
Igor Sysoev wrote:
> mod_proxy can not do many things that mod_accel can. Some of
> them can be easy implemented, some not.
Keep in mind that mod_proxy is exactly that - a proxy. It does not try
to duplicate functionality that is performed by other parts of Apache.
(This is the main reason mod_p
[EMAIL PROTECTED] wrote:
> Though I one 100% agree with the stance that a proper web server should..
> well.. serve pages - It sure would be nice if we could have a logging
> subsystem in apache 2.1 or higher which took care of some of the harder
> things for us module/appserver developers when b
On Fri, Mar 01, 2002 at 08:20:34PM -0800, Justin Erenkrantz wrote:
> On Fri, Mar 01, 2002 at 11:09:10PM +, Thom May wrote:
> > Right then. So after a fair amount of discussion on IRC, this is hopefully
> > the solution to all the configuration issues people have been hitting.
> > The only issu
37 matches
Mail list logo
