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 se
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 main
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 main
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 Developme
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
ap_send_in
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-Ma
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
ET
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 cont
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 prin
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),
T
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 n
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 Negotiat
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. I
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 p
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 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 Apa
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 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, th
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 ques
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? Wh
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 Re
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 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
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)
> chan
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 i
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 believe
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: mod_de
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. And
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 sendi
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 i
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 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
> "Destinatio
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 gen
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 chec
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-en
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 you
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
39 matches
Mail list logo
