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.packetizer.com/rfc/rfc2428
(rfc.net appeared to be offline, ton
Apart from the fact that you have it's several times when you mean
its, +1
--
Rich Bowen
[EMAIL PROTECTED]
On Oct 2, 2007, at 2:15 PM, Ruediger Pluem wrote:
-if ((r->method_number != M_OPTIONS) || !r->uri || strcmp(r-
>uri, "*")) {
-return DECLINED;
+if ((r->method_number == M_OPTIONS) && r->uri && (r->uri[0]
== '*')) {
+return OK; /* Send HTTP pong, without Allow
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> Just so everyone here knows;
>
> svn propset --revprop -r581388 svn:log "Return DONE instead of OK to
> prevent any further hooks from touching the non-URI OPTIONS * request"
>
> and it appears we now get revprop commit messages! Hooray :)
You
I don't see why we care, either way.
Roy
On 10/02/2007 11:21 PM, Jim Jagielski wrote:
>
> On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
>
>> On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
>>
>>> Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null requ
On Oct 2, 2007, at 2:21 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Tue Oct 2 14:21:04 2007
New Revision: 581389
URL: http://svn.apache.org/viewvc?rev=581389&view=rev
Log:
Ensure the URI is "*" and not something like "*foo"
I did not want that case to pass through, on purpose.
Roy
> Looks like an overloaded server to me. It is strange that there are so
> many processes in 'R' state. This looks to me as some clients are
> playing
> games with your server by connecting it but not sending a request.
The thing is, as soon as apache is stop/started, the R's disappear- if it
was
[EMAIL PROTECTED] wrote:
>
> Oh, last commit was supposed to say we need to return
> DONE so we don't invoke any handlers.
Just so everyone here knows;
svn propset --revprop -r581388 svn:log "Return DONE instead of OK to prevent any
further hooks from touching the non-URI OPTIONS * request"
and
On Oct 2, 2007, at 5:15 PM, Ruediger Pluem wrote:
On 10/02/2007 10:36 PM, [EMAIL PROTECTED] wrote:
Author: fielding
Date: Tue Oct 2 13:36:47 2007
New Revision: 581374
URL: http://svn.apache.org/viewvc?rev=581374&view=rev
Log:
Reduce the last change to a minimum, since OPTIONS * does not
in
On Oct 2, 2007, at 5:07 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/
On 10/02/2007 10:36 PM, [EMAIL PROTECTED] wrote:
> Author: fielding
> Date: Tue Oct 2 13:36:47 2007
> New Revision: 581374
>
> URL: http://svn.apache.org/viewvc?rev=581374&view=rev
> Log:
> Reduce the last change to a minimum, since OPTIONS * does not
> include an Allow header field (* is not a
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
Hmm, I am still seeing an Allow header even after my
On Tue, 2 Oct 2007 14:07:45 -0700
"Roy T. Fielding" <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
> > Nope. * is not a resource. Since it is impossible to know the
> > mask of the entire resource space, HTTP does not require that
> > Allow be included on OPTIONS
very nice... do include the last paragraph :)
On 10/2/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>
> Paul Querna wrote:
> >
> > Starting in January 2008, only critical security issues will be fixed in
> > Apache HTTP Server versions 1.3.x or 2.0.x.
>
> Actually that statement is too narro
[EMAIL PROTECTED] wrote:
> Log:
> Reduce the last change to a minimum, since OPTIONS * does not
> include an Allow header field (* is not a resource).
Ignore my previous question; obviously this makes it a non-issue.
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/Directory configs.
Could you clarify, though? If PR
Roy T. Fielding wrote:
>
> I was only talking about the OPTIONS /path case. * is a special
> case of a true null request -- it should only deal with server
> capabilities and ignore Location/Directory configs.
Could you clarify, though? If PROPGET or PUT is supported on some
subset of the serve
Paul Querna wrote:
>
> Starting in January 2008, only critical security issues will be fixed in
> Apache HTTP Server versions 1.3.x or 2.0.x.
Actually that statement is too narrow; What if we publish a manifesto such
as this?
"Apache httpd 1.3 to be retired at it's 10th anniversary"
The Apache
On Oct 2, 2007, at 12:50 PM, Jim Jagielski wrote:
The current rec does that. Since * does not map to
any storage, or, in fact to any Location, it simply creates
the Allow from the server capabilities.
Allow only applies to URIs, not *. I have a fix for that.
Roy
On Oct 2, 2007, at 3:32 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific exceptions.
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific exceptions.)
For that matter IS supported already - those
wou
Jim Jagielski wrote:
> Comments?:
Just one;
> Index: modules/http/http_core.c
> ===
> --- modules/http/http_core.c(revision 581205)
> +++ modules/http/http_core.c(working copy)
> @@ -234,6 +234,24 @@
> return OK;
> }
> +
On Oct 2, 2007, at 2:52 PM, 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 be
Jim Jagielski wrote:
>
> On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
>
>> Jim Jagielski wrote:
>>>
>>> But, as I read it, the '*' in OPTIONS * does not really
>>> mean a Location *... in other words, it's not a URI per se.
>>> OPTIONS * asks for the capabilities of the server itself,
Joe Orton wrote:
> On Mon, Oct 01, 2007 at 02:22:11AM -0500, William Rowe wrote:
>> server/Makefile.in;
>>
>> export_files:
>> tmp=export_files_unsorted.txt; \
>> rm -f $$tmp && touch $$tmp; \
>> for dir in $(EXPORT_DIRS); do \
>> ls $$dir/*.h >> $$tmp; \
>>
On 10/02/2007 08:52 PM, Paul Querna wrote:
> Jim Jagielski wrote:
>> On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
>>
>>> On 10/2/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>> Give that som
On Oct 2, 2007 11:52 AM, Paul Querna <[EMAIL PROTECTED]> 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
Jim Jagielski wrote:
>
> On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
>
>> On 10/2/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>>>
>>> On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
>>>
William A. Rowe, Jr. wrote:
>
> Give that some thought :)
One thing I'm pon
Eric Covener wrote:
>>
>> While the API might be a little ambiguous, and the caller can
>> explicitly set the timeout, is this a discrepancy APR should
>> eliminate?
>
> I'm going to add the apr_file_pipe_timeout_set(foo, 0) call instead to
> mod_ext_filter unless there are any objections.
+1
On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
On 10/2/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near future.
If only to giv
On 10/2/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
>
> > William A. Rowe, Jr. wrote:
> >>
> >> Give that some thought :)
> >
> > One thing I'm pondering is a 2.3.0 alpha in the near future.
> >
> > If only to give the "we stay back at ve
On 10/02/2007 03:16 PM, Jim Jagielski wrote:
> Comments?:
Looks fine to me.
Regards
Rüdiger
On 01.10.2007, at 12:22, Erik Abele wrote:
On 01.10.2007, at 09:58, William A. Rowe, Jr. wrote:
...
I like the idea of adding a date to each news item, be it on
httpd.a.o,
or our www.apache.org. +1.
+1, see attached patch which adds dates to the index and download
pages (see changes to
On 10/2/07, Rich Bowen <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 2, 2007, at 08:24, Jim Jagielski wrote:
>
>
> Well, we could do:
>
> o Apache 1.3 and 2.0 deprecated
>
>
>
> As part of the support community, I'd like to have this defined pretty
> clearly.
> I presume it can't mean "no more bug fixe
On Oct 2, 2007, at 10:10 AM, Rich Bowen wrote:
On Oct 2, 2007, at 08:24, Jim Jagielski wrote:
Well, we could do:
o Apache 1.3 and 2.0 deprecated
As part of the support community, I'd like to have this defined
pretty clearly.
I presume it can't mean "no more bug fixes or security fi
On Oct 2, 2007, at 08:24, Jim Jagielski wrote:
Well, we could do:
o Apache 1.3 and 2.0 deprecated
As part of the support community, I'd like to have this defined
pretty clearly.
I presume it can't mean "no more bug fixes or security fixes." I
suppose it might mean "no more fixes aft
On 9/27/07, Eric Covener <[EMAIL PROTECTED]> wrote:
> httpd's mod_ext_filter sets up a child process with a stdin of
> APR_CHILD_BLOCK, but on windows the parent side of the stdin pipe
> defaults to a "non-blocking pipe with an infinite (-1) timeout". Such
> a pipe in unix has its apr_file_pipe_ti
Comments?:
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 581205)
+++ modules/http/http_core.c(working copy)
@@ -234,6 +234,24 @@
return OK;
}
+static int http_send_options(request_rec *r)
+{
+
On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of URI... At least, that's how
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near future.
If only to give the "we stay back at version n.x-1" crowd something
to chew on.
Not to mention that it would be good f
On Mon, Oct 01, 2007 at 02:01:24AM +0100, Nick Kew wrote:
> Coadvisor has several testcases involving a Content-Type line with
> a lot of qualifier tokens. These tokens are quoted strings and
> include backslashes. This is going to wrap when I cut&paste:
>
> Content-Type: text/other; charset=IS
On Mon, Oct 01, 2007 at 02:22:11AM -0500, William Rowe wrote:
> server/Makefile.in;
>
> export_files:
> tmp=export_files_unsorted.txt; \
> rm -f $$tmp && touch $$tmp; \
> for dir in $(EXPORT_DIRS); do \
> ls $$dir/*.h >> $$tmp; \
> done; \
> for
On Tue, Oct 02, 2007 at 01:12:08AM +0100, Nick Kew wrote:
> RFC2616 mandates that a proxy MUST return interim (1xx)
> responses to an HTTP/1.1 client, except where the proxy
> itself requested the interim response. I'd interpret
> that slightly liberally, to mean we MUST return an interim
> respon
On 10/02/2007 01:04 AM, Alec Matusis wrote:
>> Have you checked without the MaxMemFree setting?
>> Why do you use MaxMemFree with such a small value at all?
>
> I finally removed MaxMemFree altogether, and it crashed again. Nothing in
> the apache error logs, but this is how /server-status looks
46 matches
Mail list logo
