William A. Rowe, Jr. wrote:
I would appreciate the active confirmation of this new parser by at
least a second set of eyeballs. We all know how notorious parsers
are at creating holes in the security of fresh software and code.
The relevant RFC is;
http://www.ietf.org/rfc/rfc2428.txt
Hi,
I think mod_proxy should be enhanced/fixed in some way:
- If I use ProxyPass ProxyPassReverse to forward connection from
proxy to back-end, ProxyPassReverse adapts the Location header
from back-end/... to proxy/
1. Why only the Location header ?
2. In case you access your proxy in
On Wed, 03 Oct 2007 12:11:09 +0200
Nick Gearls [EMAIL PROTECTED] wrote:
Hi,
I think mod_proxy should be enhanced/fixed in some way:
- If I use ProxyPass ProxyPassReverse to forward connection from
proxy to back-end, ProxyPassReverse adapts the Location header
from back-end/... to
Maybe I didn't describe the global picture, sorry.
There are obviously known headers that will never contain a URL, like
the Date you mentioned, and several others.
However, you may have other headers containing the host URL, like
Destination for the WebDAV protocol.
So, I was asking to check
On Wed, 03 Oct 2007 12:44:28 +0200
Nick Gearls [EMAIL PROTECTED] wrote:
I personally have the problem with WebDAV, which is obviously a
common one because of the standard, so we could fix only that header;
but I imagine some other applications could use the same mechanism,
so why not
On 10/03/2007 12:44 PM, Nick Gearls wrote:
Maybe I didn't describe the global picture, sorry.
There are obviously known headers that will never contain a URL, like
the Date you mentioned, and several others.
However, you may have other headers containing the host URL, like
Destination for
On Wed, October 3, 2007 1:03 pm, Nick Kew wrote:
It would break headers that contain a URL-like pattern that isn't
a URL. And if you think that's unlikely, just look at the number
of false positives in desktop software (e.g. mailers) that guesses
links and makes http://www.example.org or
On Oct 2, 2007, at 5:56 PM, Ruediger Pluem wrote:
Slightly off topic, but this gives me the idea that we could use
OPTIONS * as some kind of ping / health check for pooled connections
in mod_proxy_http before sending a request (at least in the reverse
proxy case before sending a request that
Jim Jagielski wrote:
On Oct 2, 2007, at 5:56 PM, Ruediger Pluem wrote:
Slightly off topic, but this gives me the idea that we could use
OPTIONS * as some kind of ping / health check for pooled connections
in mod_proxy_http before sending a request (at least in the reverse
proxy case before
I agree, we have to check if it latches the back-end before changing it
to the front-end, and vice-versa.
This way, it sounds totally safe, no ?
Graham Leggett wrote:
On Wed, October 3, 2007 1:03 pm, Nick Kew wrote:
It would break headers that contain a URL-like pattern that isn't
a URL.
On 02.10.2007, at 20:52, Paul Querna wrote:
So, the first step is to cut out any illusion that new features are
going into 1.3, with a statement like this:
Starting in January 2008, only critical security issues will be
fixed in
Apache HTTP Server versions 1.3.x or 2.0.x.
I honestly
On Wed, 03 Oct 2007 15:04:52 +0200
Rainer Jung [EMAIL PROTECTED] wrote:
It would be nice to have the health check running asynchronously from
the normal request handling (error detection for idle connections,
before requests fail). Even more important, the recovery test could
be done
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
changes to Content-Encoding?
Summary:
Original bug:
On ons, 2007-10-03 at 14:23 +0100, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
On 10/03/2007 03:23 PM, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental question: Does a weak ETag preclude (negotiated)
changes to
On Oct 3, 2007 7:20 AM, Henrik Nordstrom [EMAIL PROTECTED] wrote:
deflates the contents. Rationale: a weak ETag promises
equivalent but not byte-by-byte identical contents, and
that's exactly what you have with mod_deflate.
I disagree. It's two very different entities.
As before, I still
Roy T. Fielding wrote:
I don't see why we care, either way.
Could you clarify what we aren't caring about, since your answer was
a bit ambiguous? (Abandon or not, message our users or not, etc)
On 10/3/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
AIUI this is the desired default behavior from apr; why change httpd
at all? I was receptive to your suggestion/patch to resolve this as
the default on apr 0.9/1.2/1.x branches, per the unix implementation.
I think I misunderstood
AIUI this is the desired default behavior from apr; why change httpd
at all? I was receptive to your suggestion/patch to resolve this as
the default on apr 0.9/1.2/1.x branches, per the unix implementation.
Bill
[EMAIL PROTECTED] wrote:
Author: covener
Date: Wed Oct 3 10:17:24 2007
New
On Oct 3, 2007, at 8:30 AM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I don't see why we care, either way.
Could you clarify what we aren't caring about, since your answer was
a bit ambiguous? (Abandon or not, message our users or not, etc)
Why do we need to announce anything?
On Oct 3, 2007, at 7:20 AM, Henrik Nordstrom wrote:
On ons, 2007-10-03 at 14:23 +0100, Nick Kew wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
We have some controversy surrounding this bug, and bugzilla
has turned into a technical discussion that belongs here.
Fundamental
On 10/3/07, Roy T. Fielding [EMAIL PROTECTED] wrote:
I don't care what the uptake graph says. I don't care what people
outside this project mailing list think, period, about this project.
And if five years from now there are three or more Apache committers
that want to release 1.3.x, then no
On Oct 3, 2007, at 7:53 AM, Justin Erenkrantz wrote:
The problem with trying to invent new ETags is that we'll almost
certainly break conditional requests and I find that a total
non-starter. Your suggestion of appending ;gzip leaks information
that doesn't belong in the ETag - as it is quite
On Oct 3, 2007, at 3:15 PM, Joshua Slive wrote:
On 10/3/07, Roy T. Fielding [EMAIL PROTECTED] wrote:
I don't care what the uptake graph says. I don't care what people
outside this project mailing list think, period, about this project.
And if five years from now there are three or more
On Oct 3, 2007 12:19 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
I don't see how that is possible, unless subversion is depending
on content-encoding to twiddle between compressed and uncompressed
transfer without changing the etag. In that case, subversion will be
broken, as would any
On Wed, 3 Oct 2007 07:53:31 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
[chop]
The Cc: list on this and subsequent postings is screwed:
(1) It includes me, so I get everything twice.
OK, I can live with that, but it's annoying.
(2) It fails to include Henrik Nordstrom, the
Joshua Slive wrote:
We have better things to do. Let's do those things and stop worrying
about other people's perceptions.
I agree, with a caveat. I think that we are doing a disservice to our
users if we don't communicate to them the attitude of the people on
this mailing list towards 1.3.
On ons, 2007-10-03 at 07:53 -0700, Justin Erenkrantz wrote:
As before, I still don't understand why Vary is not sufficient to
allow real-world clients to differentiate here. If Squid is ignoring
Vary, then it does so at its own peril - regardless of ETags.
See RFC2616 13.6 Caching Negotiated
Roy T. Fielding wrote:
I don't see why we care, either way.
I don't care if committers continue to maintain 1.3 longer than any
statement we make.
A public statement is about setting expectations of our users.
We all know that 1.3 is dead as a doornail at this point, but many of
our users do
On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests. But, if mod_deflate always strips a 'special' tag from the
ETag (per Henrik),
That
On ons, 2007-10-03 at 12:10 -0700, Roy T. Fielding wrote:
Two resource variants with different content-encoding is not
semantically equivalent as the recipient may not be able to understand
an variant sent with an incompatible encoding.
That is not true. The weak etag is for content
On ons, 2007-10-03 at 21:44 +0100, Nick Kew wrote:
The Cc: list on this and subsequent postings is screwed:
(1) It includes me, so I get everything twice.
OK, I can live with that, but it's annoying.
Use a Message-Id filter?
(2) It fails to include Henrik Nordstrom, the
Henrik Nordstrom wrote:
On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests. But, if mod_deflate always strips a 'special' tag from the
On ons, 2007-10-03 at 23:52 +0200, Henrik Nordstrom wrote:
That is not HTTP. Don't confuse the needs of caching with the needs
of range requests -- only range requests need strong etags.
I am not. I am talking about If-None-Match, not If-Range. And
specifically the use of If-None-Match in
RFC2616 tells us a proxy MUST forward interim (1xx) responses
to an HTTP/1.1 Client, except where the proxy itself requested
the response. Currently mod_proxy is just eating interim
responses. There's a history of problems here (PR#16518).
I've hacked up a simple patch, based on a new
On Thu, 4 Oct 2007 00:41:06 +0100
Nick Kew [EMAIL PROTECTED] wrote:
Patch attached. Comments?
OK, slightly dumb patch. Correction is to write to
r-connection-output_filters, not bypass the whole chain!
/me heads for bed before doing more dumb things
--
Nick Kew
Application Development
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2007-10-03 01:18:51 -0400 (Wed, 03 Oct 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
Documentation status is
APACHE 2.2 STATUS: -*-text-*-
Last modified at [$Date: 2007-10-03 01:17:42 -0400 (Wed, 03 Oct 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Documentation status is
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained
39 matches
Mail list logo
