have binding votes on mod_python (i.e., who has earned it),
keeping in mind that you need at least three binding +1 votes in
order to make any release at Apache, and send me a list of names
and email addresses of those people so that I can properly
record them in our records.
Cheers,
Roy T
On Jan 11, 2006, at 7:19 AM, Joshua Slive wrote:
[Your merge today prompted me to dig out a response I started but
never finished.]
I am still worried that we are underestimating the pain that this will
cause. In my opinion, a config change that requires substantial
changes to every
For someone looking for something to do,
The authorization code makes an assumption that filesystems allowing
file ownership is a platform-specific define. That is not
the case for the same reason that case-sensitivity is not based
on the platform. All of the filesystem characteristics should
On Jan 5, 2006, at 4:49 AM, [EMAIL PROTECTED] wrote:
+In order to handle empty boundaries, we'll look for the
+boundary plus the \n. */
+
+ boundary_line = apr_pstrcat(p, --, mail-boundary, \n, NULL);
/* The start boundary */
- bound = ap_strstr(mail-body,
It might be a good project for someone to take this I-D and convert
it to an apache utility library.
Roy
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: January 4, 2006 12:50:01 PM PST
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-eastlake-sha2-01.txt
Reply-To: [EMAIL
On Jan 3, 2006, at 12:02 AM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other
MPMs),
then I am all ears. I am
I meant that you should have one directory of docs per major version
number. I.e.,
docs-2/ (trunk until you release 3)
docs-1/ (1.x branch)
instead of
docs/2.06/
docs/1.3/
docs/ (trunk)
The reason being that we don't want external links (including
those in the README of
On Dec 31, 2005, at 9:55 PM, Brian Pane wrote:
On Dec 31, 2005, at 6:50 PM, Roy T. Fielding wrote:
The nonblocking yield should happen inside ap_rgetline (or its
replacement), not in the calling routine. The thread has nothing
to do until that call is finished or it times out
On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:
Significantly faster than prefork has never been a litmus test for
assessing new features, and I'm -1 for adding it now. A reasonable
technical metric for validating the async changes would significantly
more scalable than the 2.2 Event MPM or
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other
MPMs),
then I am all ears. I am easily convinced by comparative performance
figures when the comparison
On Dec 31, 2005, at 3:45 PM, [EMAIL PROTECTED] wrote:
Author: brianp
Date: Sat Dec 31 15:45:11 2005
New Revision: 360461
URL: http://svn.apache.org/viewcvs?rev=360461view=rev
Log:
Refactoring of ap_read_request() to store partial request state
in the request rec. The point of this is to allow
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try
using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node-next node-index current_free_index)
is true, then the do { } while
It looks like an autobot was fooled into subscribing here.
I have removed it and added it to the deny list.
Roy
On Dec 23, 2005, at 10:34 AM, Maxime Petazzoni wrote:
Ok, updated tarballs have been uploaded to
http://httpd.apache.org/dev/dist/mod_mbox. Vote is restarted.
They should be called 0.2.1, though I'll let that pass as there were
no code changes. However, you do need to remember to check the
You guys are confusing each other to bits. We don't have release
candidates, we NEVER use m.n.v.rc1 versioning, and the thing that
Sam produced is called a tarball. We call it that because we don't
want people to believe it is a release until the PMC has voted to
release it. That's all there
On Dec 21, 2005, at 2:54 PM, Sander Temme wrote:
On Dec 21, 2005, at 11:16 PM, Maxime Petazzoni wrote:
Of course, since this tag is currently running like a charm on Ajax,
my vote is +1 for GA.
Like a charm, indeed. Zero cores since this morning CET.
+1 for GA.
-1. Er, sorry, I was about
On Dec 21, 2005, at 4:45 PM, Paul Querna wrote:
Roy T. Fielding wrote:
Sorry, NOTICE is not a credits file. Add a README instead that lists
all of the contributors. Likewise, the scripts directory sucks
beyond
description. If you aren't going to fix it, then remove it from the
release
On Dec 21, 2005, at 4:51 PM, Maxime Petazzoni wrote:
* Paul Querna [EMAIL PROTECTED] [2005-12-21 16:45:09]:
What specifically is wrong with the scripts directory?
Scripts are mostly specific to the ASF setup for
mail-archives.apache.org. They're not involved in making the module
work for
On Dec 21, 2005, at 5:15 PM, Paul Querna wrote:
I agree with all points, except the last. They do work, they are
running mail-archives.apache.org.
No, an edited version of them is doing a poor job of occasionally
being manually used to update our mailing lists. I just ran into
that problem
On Dec 16, 2005, at 12:41 AM, Plüm, Rüdiger, VIS wrote:
I do not intend to do close the connection by myself. Currently it
will be closed because c-keepalive is set to AP_CONN_CLOSE
(a approach also suggested in Roys patch).
Right, the important bit is that the code managing the client
On Dec 10, 2005, at 4:15 PM, [EMAIL PROTECTED] wrote:
Author: rpluem
Date: Sat Dec 10 16:15:27 2005
New Revision: 355823
URL: http://svn.apache.org/viewcvs?rev=355823view=rev
Log:
* Move handling of backends that broke after the headers have been
sent
into the proxy handler of mod_proxy.
On Dec 10, 2005, at 5:02 PM, Justin Erenkrantz wrote:
That will get mod_cache not to pick up on it, right. However, it
won't
force the connection to close. Or, give anything a chance to close
it: be
it HTTP/1.1 or Waka. =) -- justin
Right, that was just the proxy part -- the other half
On Dec 10, 2005, at 5:30 PM, Ruediger Pluem wrote:
But with your approach you need to double the code in *each* scheme
handler.
mod_mem_cache doesn't look like it works right now. I haven't looked
at the other schemes yet.
r355823 tries to avoid this by doing it a little later in the proxy
On Dec 8, 2005, at 6:58 AM, Justin Erenkrantz wrote:
On Wed, Dec 07, 2005 at 06:16:42PM -0800, Roy Fielding wrote:
Setting the inbound c-aborted within a filter just to indicate
that the outbound connection has died is wrong -- it prevents
other parts of the server (that are working fine) from
On Dec 8, 2005, at 9:21 PM, Justin Erenkrantz wrote:
Even with an EOS bucket, how will we indicate that the connection
should be
aborted? (i.e. don't try to do any further writes?)
The inbound connection hasn't been aborted -- only the outbound.
We don't even want to abort the inbound
On Dec 7, 2005, at 8:44 AM, Plüm, Rüdiger, VIS wrote:
Nope, that's the flag we set when we want the core to drop
the connection. I thought that it would be set by the filters
when a connection was dropped, but, as I said earlier in this
thread, I'm wrong. The filters will never ever set it. --
On Dec 6, 2005, at 9:38 AM, Justin Erenkrantz wrote:
On Tue, Dec 06, 2005 at 12:22:18PM -0500, Brian Akins wrote:
There *might* be a breakage if the server aborted it's half of the
connection partway through the response. I don't have the time
to fully
look at the code, but there might be a
On Dec 6, 2005, at 12:45 PM, Brian Akins wrote:
That would work, I suppose, but wouldn't the client get the same
impression proxy is broken? I generally only deal with reverse
proxies, so if origin is broken, whole site is broken...
Sorry, reverse proxy is not a proxy -- it is a gateway.
On Dec 5, 2005, at 10:19 AM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
But the obvious tangle becomes - do we return T-E chunked - and is
that
a valid header as a HEAD response with no body?
From 2616 4.3,
For response messages, whether or not a message-body is included
On Dec 2, 2005, at 5:24 AM, William A. Rowe, Jr. wrote:
With this single change, there is now a source package available at;
httpd.apache.org/dev/dist/httpd-2.2.0-win32-src.zip
However, without this single change it was impossible for nmake -f
to run
to completion.
Is it unreasonable to
On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote:
I'm 100% conviced next to nobody on this list has been developing
and testing
httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty
as anyone.
So we've been compiling and improving the code, but the build/
install
+qPQnF9uCcmV+n/ZUFW8jTo=
=HJ0S
-END PGP SIGNATURE-
Cheers,
Roy T. Fieldinghttp://roy.gbiv.com/
Chief Scientist, Day Software http://www.day.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (Darwin
On Nov 28, 2005, at 5:53 PM, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Mon Nov 28 17:53:31 2005
New Revision: 349582
URL: http://svn.apache.org/viewcvs?rev=349582view=rev
Log:
Tag 2.2.0 from 2.1.10 tag to prepare for the 2.2.0 release
What? No, sorry, -1. Your vote was on releasing
On Nov 28, 2005, at 6:13 PM, Paul Querna wrote:
Roy T. Fielding wrote:
On Nov 28, 2005, at 5:53 PM, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Mon Nov 28 17:53:31 2005
New Revision: 349582
URL: http://svn.apache.org/viewcvs?rev=349582view=rev
Log:
Tag 2.2.0 from 2.1.10 tag to prepare
On Nov 22, 2005, at 5:35 AM, Jim Jagielski wrote:
Wayne S. Frazee wrote:
The Apache HTTP Server Project is proud to announce the release of
version
2.1.9-beta of the Apache HTTP Server (Apache).
This version of Apache is a Beta release of the unstable development
branch.
New features
On Nov 18, 2005, at 11:39 AM, William A. Rowe, Jr. wrote:
Roy's raised the recent issue that all ASF releases under his domain
(httpd project chair) should be reviewed -by at least three pmc
members-
as well as the contributors and committers.
This raises an obvious question; are binary
Much to my surprise, I apparently have a board report due yesterday
for this Wednesday's board meeting. Do we have any ASF issues that
need reporting to the board, aside from what is in STATUS*?
Any choice commentary? Does anyone else feel like we have too many
dev lists for one project?
Much to my surprise, I apparently have a board report due yesterday
for this Wednesday's board meeting. Do we have any ASF issues that
need reporting to the board, aside from what is in STATUS*?
Any choice commentary? Does anyone else feel like we have too many
dev lists for one project?
Much to my surprise, I apparently have a board report due yesterday
for this Wednesday's board meeting. Do we have any ASF issues that
need reporting to the board, aside from what is in STATUS*?
Any choice commentary? Does anyone else feel like we have too many
dev lists for one project?
Much to my surprise, I apparently have a board report due yesterday
for this Wednesday's board meeting. Do we have any ASF issues that
need reporting to the board, aside from what is in STATUS*?
Any choice commentary? Does anyone else feel like we have too many
dev lists for one project?
On Nov 7, 2005, at 2:06 AM, Nick Kew wrote:
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like 'faking' a header out
of remote-ip.
Why? All you
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option,
but I
think we should default to the safe option for now.
The compelling reason is that this implies that
On Nov 7, 2005, at 2:09 PM, Ruediger Pluem wrote:
The problem is that without Cache-Control: private, any downstream
cache
would have the exact same problem. There's no way for it to know that
the response differs based on IPs unless the Origin says so. --
justin
This is true. But in the
On Nov 7, 2005, at 3:03 PM, Ruediger Pluem wrote:
Just checking if I understood things correctly:
If I have a forward proxy to which I limit access via IP based access
control
I should add Cache-Control: private to any response I get back from
the backend
(either a Remote Proxy or the origin
On Nov 7, 2005, at 3:10 PM, Ruediger Pluem wrote:
Not for every page, but if I get it right once you lock out one bad
boy via
deny ipaddress
than it should be sent. AFAIK this not done automatically currently
once you add a deny
directive somewhere. Does this need to be changed?
I can't
On Nov 4, 2005, at 10:56 AM, William A. Rowe, Jr. wrote:
It leaves us wondering; how can allow from/deny from n.n.n.n be mapped
to
RFC 2616 semantics, or at least, without running the many server hooks
on
later requests? The only way I can see, is that we should have any
more
explicit allow
c = ap_strchr_c(url, ':');
if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0')
return NULL;
BTW, unless url is somehow limited to http and ftp, the above
is bad code. The proxy should be able to handle arbitrary
schemes (eventually), which means requiring scheme://host
On Oct 19, 2005, at 8:35 AM, Greg Ames wrote:
let's say it is a HEAD request for a local static file. the
default_handler calls ap_set_content_length which creates a C-L
header. but then the body could be run through some length changing
filter, such as mod_deflate or mod_include,
On Oct 18, 2005, at 3:58 PM, Greg Ames wrote:
Index: server/protocol.c
===
--- server/protocol.c (revision 326257)
+++ server/protocol.c (working copy)
@@ -1302,7 +1302,13 @@
* We can only set a C-L in the response header
I objected to this code when it was first added (13 Aug 1996)
as part of Alexei's huge HTTP/1.1 patch and for some unknown
reason I forgot to remove it.
http://mail-archives.apache.org/mod_mbox/httpd-dev/199608.mbox/
[EMAIL PROTECTED]
It has been featured in multiple PRs since then for both
On Oct 14, 2005, at 12:39 PM, Roy T. Fielding wrote:
On Oct 14, 2005, at 2:55 AM, Joe Orton wrote:
On Thu, Oct 13, 2005 at 07:50:27PM -0700, Roy T. Fielding wrote:
I just tried to add
Redirect Permanent /dist/jakarta/tomcat
http://www.apache.org/dist/tomcat/tomcat
to a .htaccess on ajax
I just tried to add
Redirect Permanent /dist/jakarta/tomcat
http://www.apache.org/dist/tomcat/tomcat
to a .htaccess on ajax and the prefix match/replace didn't work.
I had to replace it with
RedirectMatch Permanent /dist/jakarta/tomcat(.*)$
http://www.apache.org/dist/tomcat/tomcat$1
to
On that note, we should look for someone else to take over
mail-archives.apache.org. I'm getting flooded with a bunch of errors
due to Roy removing or renaming some ASF lists.
What errors? Do you mean 404s on httpd (what I would expect) or
script errors on mbox processing (what I wouldn't
The RFC 2616 says
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method (section
We have no need to support anything other than the latest updates
of Win2k and WinXP. Anything other than that should not be running
a server and can continue using our old builds if needed.
Roy
out of retirement
and be the new conveyer of choice words between this project
and the board.
Should I add anything else? Could the people who accepted PMC
or committer status in the past three months please remind me
to include your name in the report? Thanks.
Cheers,
Roy T. Fielding
On Aug 8, 2005, at 10:55 PM, Aaron Bannert wrote:
I can't believe you guys are still debating the merits of RTC over CTR
after all this time. RTC killed the momentum in this project a long
time
ago.
That doesn't make sense, Aaron. The other branches are CTR and
I don't see anyone making
On Aug 9, 2005, at 11:28 AM, Aaron Bannert wrote:
I'm not talking about 2.2. I'm talking about a severe slowdown in the
pace of development on this entire project.
Less talk, more do.
And it sounds like you've been feeling the effects of all the red tape
too, with being fed up trying to
Any change that hasn't been released can be vetoed if a technical
explanation is given. If you don't have time to fix it immediately,
then the person who committed the change is required to back the
change out to the point where we are back to the prior release code.
If you don't like that,
Bill, if you spent more time making your changes understandable
by documenting what they change instead of various random things
totally unrelated to each patch, then maybe people like me could
review them. Also, it would help a great deal if you would make
a complete set of changes locally,
On Aug 8, 2005, at 5:24 PM, William A. Rowe, Jr. wrote:
At 06:27 PM 8/8/2005, Roy T. Fielding wrote:
Any change that hasn't been released can be vetoed if a technical
explanation is given.
Roy; I -totally- agree with your position. However, emails going
back to 1997 of http
Yeah, no kidding. We haven't made any decisions yet. Decisions
are what happens when people vote on releases or changes. Did one
of those go by and I didn't notice? Nope.
Yup - branching 2.1.x - 2.2.x - trunk.
No, branching is part of the task of an RM. It is not a decision
of the group,
On Jul 18, 2005, at 12:30 PM, William A. Rowe, Jr. wrote:
NTLM HTTP Authentication
(and possibly other connection-oriented
HTTP authentication and authorization protocols)
is insecure by design
Yep, no shit -- that's what the
On Jul 18, 2005, at 10:26 AM, William A. Rowe, Jr. wrote:
Please remember that decisions need to be made on [EMAIL PROTECTED]
Hopefully high-bandwidth discussions will generate some pretty
slick code and solutions. Although those in the rest of the
world will be lagging a bit, the history of
Thanks Paul, you just collided with the refactoring of 2.1.x proxy.
That isn't possible. Trunk is still trunk.
Thank you for not announcing this first.
That isn't necessary.
Thank you for ignoring the entire user community in your zeal
to move forward with ... what?
Preparing a tarball
-1 This is a violation of HTTP:
+if (apr_table_get(r-subprocess_env, force-proxy-request-1.0)
+ || ((r-proto_num HTTP_VERSION(1,1))
+ !apr_table_get(r-subprocess_env,
force-proxy-request-1.1))) {
In all cases except when specifically configured otherwise,
the proxy
* RFC 2616 says
All HTTP/1.1 applications MUST be able to receive and decode the
chunked transfer-coding, and MUST ignore chunk-extension
extensions
they do not understand.
I read this as an HTTP/1.1 server must accept chunked or quit
reporting it complies with the
On Jul 11, 2005, at 9:06 PM, Maxime Petazzoni wrote:
As promised : a first try at XHTML mockup. Comments about DOM
structure and XHTML semantics are welcome !
http://skikda.bulix.org/~sam/ajax/jsless/
2005 | It looks great except for all the wasted whitespace.
Jul | One thing I look for
On Jul 5, 2005, at 1:41 PM, William A. Rowe, Jr. wrote:
RFC2616 says TRACE doesn't accept a body.
Patches I'd committed to 1.3.x and working on 2.1.x (to port
to 2.0.x) enforce this with TraceEnable On.
But what about a 0-byte body?
Content-Length: 0
Is the same as no message body.
On Jul 5, 2005, at 8:56 PM, William A. Rowe, Jr. wrote:
Attached is the mystery patch [omitted from the last note - whoops].
IMHO we should apply the same to ap_http_filter() in 2.1's
http_filters.c
It looks like a band-aid to me -- how does this module know that
the server doesn't support
On Jul 3, 2005, at 1:29 AM, Paul Querna wrote:
I believe the core goal is separation of data from presentation.
No, the core goal is to provide an ultra-efficient interface to
large mail archives. The data is already available in mbox form.
The standard reply is to use some kind of template
On Jul 3, 2005, at 4:18 AM, Maxime Petazzoni wrote:
+1. XML has the particularity to describe only the data, as opposed to
XHTML which stores data *and* structure information.
No, XML is a data structuring (mark-up) metalanguage. The only
difference between arbitrary XML and XHTML is that
On Jul 2, 2005, at 7:46 PM, Maxime Petazzoni wrote:
The main goal of my SoC project is to enhance mod_mbox's interface by
using newer web development techniques and/or technologies, while
avoiding any noticeable slowdowns.
That's good, but keep in mind the general design principle to
avoid
On Jun 29, 2005, at 6:09 AM, Ian Holsman wrote:
and where do we put the code?
Wherever you want the code to be, so long as it isn't released
until you get three binding +1s.
This isn't the first time that new people working on httpd-related
projects have been given limited commit access. I
On Jun 28, 2005, at 4:20 PM, Paul Querna wrote:
So, to accommodate this, we would need a mod_smtpd space in subversion
and a [EMAIL PROTECTED] mailing list.
-1. The point of SoC is to get more people involved in open
source projects, not to encourage the ASF to accept
non-collaborative code
On Jun 23, 2005, at 6:53 AM, William A. Rowe, Jr. wrote:
The patch, in final form, tested and works for T-E with C-L body,
T-E with C-L body, C-L only, T-E only and no body. It correctly
denies proxy TRACE with a body by default, and will deny all TRACE
requests for 'TraceEnable off'.
Votes
On Apr 17, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote:
+
+ *) mod_deflate: Merge the Vary header, isntead of Setting it. Fixes
+ applications that send the Vary Header themselves, and also apply
+ mod_defalte as an output filter. [Paul Querna]
*) mod_rewrite: use buffered I/O for
IMO, it should be off by default on all httpd versions, just
as the config should default to no access. Personally, I would
prefer that all of the defaults be set internal to the server
such that a running httpd with an empty status file would only
be capable of responding successfully to / with
2.1.3 : Released on 2/22/2005 as alpha.
It had enough votes for beta, but I am not sure on the RM's decision.
It isn't the RM's decision. A majority vote of the PMC is a decision
to release provided there are at least three +1s. The RM is just the
person doing the heavy lifting.
Roy
and trying to make progress while at the same
time trying to make sense of your cryptic problem reports and
not step on any toes. At some point we have to stop trying to
reach consensus on every platform and just make progress on
those platforms with bodies to support them.
Cheers,
Roy T. Fielding
proud of what we have accomplished
and very grateful to have met so many friends along the way.
Cheers,
Roy T. Fieldinghttp://roy.gbiv.com/
Chief Scientist, Day Software http://www.day.com/
On Feb 19, 2005, at 11:02 AM, Arne Thomassen wrote:
But I disagree with your interpretation of the specification. 14.23
says
port number [...] as obtained from the original URI, and 3.2.2 says
If the port is empty or not given, port 80 is assumed. So the client
obtained the port number by
/will you solve the problem inside httpd
somehow?
No.
And how could I change the request header to avoid the problem
with existing httpd versions?
Yes, don't add the port to Host unless it was present in the URI.
Cheers,
Roy T. Fieldinghttp://roy.gbiv.com/
Chief Scientist
On Jan 1, 2005, at 1:38 PM, Justin Erenkrantz wrote:
Apache 1.3 does not support chunked request bodies. (All 2.x GA
releases
do though.) So, that factors very much in the reason that I don't
think
we should send chunks by default: all requests to 1.3.x would receive
some 4xx (413??) error if
I've looked back at the Jan-Feb 2000 discussion regarding cross-site
scripting in an attempt to find out why AddDefaultCharset is being
set to iso-8859-1 in 2.x (but not in 1.3.x). I can't find any rationale
for that behavior -- in fact, several people pointed out that it would
be inappropriate
On Dec 10, 2004, at 4:19 AM, Joe Orton wrote:
My understanding was that the forced default charset *does* prevent
browsers (or maybe, MSIE) from guessing the charset as UTF-7; UTF-7
being the special case as it's already an escaped encoding and hence
defies normal escaping-of-client-provided-data
On Dec 9, 2004, at 8:46 AM, Justin Erenkrantz wrote:
--On Thursday, December 9, 2004 11:26 AM -0500 Geoffrey Young
[EMAIL PROTECTED] wrote:
well, I guess it depends on whether the goal is to help (for some
definition
of help) support official HTTP variants (if indeed that's what 3229
is), or
On Dec 6, 2004, at 7:53 PM, Paul Querna wrote:
I do not agree that using writev() would allow multiple children from
scribbling over each other's log entries. I have not been able to
cause this to happen on my local machines.
You might want to consider what happens on all of the not so recent
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
Okay, but why the next three lines? Why would Content-Encoding: gzip
*ever* be set on a 304?
Because Content-* header fields in a 304 response describe
what the response entity would contain if it were a 200 response.
Therefore, the header field
I happen to agree that the commit messages suck, but the right thing
to do is have a look at the script and suggest a patch on the
infrastructure mailing list. I would do it myself, but have a paper
to write first. I also think that placement of the Log text after
the long list of files is
What would make more sense is Error while reading HTTP request line.
(remote browser didn't send a request?). This indicates exactly what
httpd was trying to do when the error occurred, and gives a hint of
why the error might have occurred.
We used to have such a message. It was removed from
whoa! -1
Was this even discussed on the list? You just changed the
entire module API and introduced a dozen potential security holes.
Why on earth is it changing nvec to apr_size_t and then downcasting
its use? Why is any of this even needed?
Roy
On Oct 22, 2004, at 8:22 AM, [EMAIL
The precursor to this patch [PATCH] WIN64: httpd API changes
was posted 10/7 so I thought we had had suitable time for
discussion. I have addressed the one issue that was raised.
That explains why I didn't see it -- I was in Switzerland.
There have also been several other threads on the httpd apr
+1 Subversion still lacks a few features in commit notices, and
I don't see the equivalent of viewcvs diff (must be hidden
somewhere), but the developer interaction is much better.
What are we going to use for trunk names? httpd-1.3 and httpd-2?
I wonder how hard it would be to make
Why do we merge multiple Host headers? I am getting wierd things like
this for headers_in host: www.cnn.com, www.cnn.com
This may be correct, but it caught me by surprise!
Well, it is an invalid HTTP request. The question is, should be
fix it for the client by choosing either the first or last
Just a thought... why does this restriction exist in the first place?
Because, a long time ago, queries contained mostly user-defined
strings that were not likely to result in a later hit, so it wasn't
worth the effort. Now, some web applications use a bogus query
string in order to override
-0.9. This change needs review. The coding style should stick to
the httpd guidelines. Use of sprintf into a small fixed size
buffer is unwise (even when we know it fits) .. use
apr_snprintf.
Also, we don't add comments to a credit log inside the file
(instead
On Sep 3, 2004, at 6:06 PM, Paul Querna wrote:
On Fri, 2004-09-03 at 16:06 -0700, Roy T. Fielding wrote:
-0.9. This change needs review. The coding style should stick to
the httpd guidelines.
Yes, but I did not commit a correct style patch, because that would of
been *impossible
[sent this yesterday, but it bounced]
personally, I tend to see it more from doug and nick's perspective and
would
be inclined to fix a long-standing issue that never made sense to me,
but
roy wrote the book and has unique insight here, so...
Umm, not really -- cookies are just broken by design.
This doesn't look right. Checking the notes table is a serious
performance hit, and why does it matter how many times keepalives
is incremented on an error path? There must be a better way to do this.
Roy
On Friday, August 27, 2004, at 04:44 PM, [EMAIL PROTECTED] wrote:
jim
301 - 400 of 552 matches
Mail list logo
