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 issue now is
[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
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
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
Header,
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 this
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
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
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 Pine.BSF.4.21.0202240946360.45832-10@is.
Regards,
Graham
--
-
[EMAIL PROTECTED]
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 -
if
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 Jagielski
*) 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 for the
[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
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 by other
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 */
+/* make
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' Ie even if an
module provides an 'OK' it continues just as a 'DECLINE' so that certain
major failures can
Watch out on the seealsos They are only allowed under modulesynopsis
or directivesynopsis and should each be in a separate tag set, without
the words see also as in:
seealsoa href=/logshtmlLog Files/a/seealso
seealsoa href=/envhtmlEnvironment Variables/a/seealso
Which will be presented
[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
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 Proxy directive. However, there seems no 'trivial' way to do so,
unless Proxy * would accomplish this.
If we don't support a 'none'
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 some drawbacks that
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
Justin
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 back
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
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
information.
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
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
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 20 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 corners
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
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 point
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
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.
--
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 just making
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
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
33 matches
Mail list logo
