Would someone be kind enough to show me the lines in
their httpd.conf file that deal with mod_mbox?
Jeffrey Horner [EMAIL PROTECTED] writes:
Since I set the brigade limit to 0, libapreq will generate a brigade with 1
spool bucket for each file param uploaded. Poking through the libapreq
code and the apr code, I see that on UNIX that writev() is called to
ultimately write to the spool file.
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 Wed, Jul 06, 2005 at 02:53:52PM -0400, Jim Jagielski wrote:
On Jul 6, 2005, at 2:22 PM, Joe Orton wrote:
On Wed, Jul 06, 2005 at 11:45:21AM -0500, William Rowe wrote:
...
+else {
+char *len_end;
+errno = 0;
+c-len =
Hi,
it has been some time since the original thread.
This is in reply to [1].
Sander Striker wrote:
[EMAIL PROTECTED] wrote:
The problem seems to be, that the proxied backend server that is
cached via mod_disk_cache originally
delivers HTTP status 301 and the Location
At 08:35 AM 7/7/2005, Roy T. Fielding wrote:
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
At 08:30 AM 7/7/2005, Roy T. Fielding wrote:
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:
Joe Orton wrote:
An empty string, right: I think it's certainly correct to treat that as
invalid C-L header;
Bill just asked Roy about this very question.
indeed some strtol's themselves set errno for that
case. (the perl-framework C-L tests picked up this inconsistency a
while
Joe Orton wrote:
An empty string, right: I think it's certainly correct to treat that as
invalid C-L header;
While we wait on Roy's response, my own PoV is that we should
accept it and assume it means '0', so be as lenient and forgiving
as possible in input (be generous in input, rigorous
On Thu, Jul 07, 2005 at 11:03:33AM -0500, William Rowe wrote:
Cool. Thank you for the clarification. Final question, please
verify my guess that;
Content-Length:
is the same as
Content-Length: 0
Why would you assume that?
RFC2616, 14.13:
Content-Length= Content-Length :
At 12:09 PM 7/7/2005, Jim Jagielski wrote:
This was, iirc, to handle cases where a strtol could possibly set it
to NULL; someone, can't recall who, seemed to remember one implementation
which did that, so we just figured to-hell-with-it and add a safety
check, just in case :)
In httpd-1.3,
William A. Rowe, Jr. wrote:
At 12:09 PM 7/7/2005, Jim Jagielski wrote:
This was, iirc, to handle cases where a strtol could possibly set it
to NULL; someone, can't recall who, seemed to remember one implementation
which did that, so we just figured to-hell-with-it and add a safety
check,
On Thu, Jul 07, 2005 at 12:46:03PM -0500, William Rowe wrote:
I didn't assume; I guessed :)
Thank you for that observation Joe,
Content-Length:
is most definitely invalid according to the grammar. Although
the grammar doesn't account for
Content-Length: 0
0 does match 1*DIGIT -
--On July 6, 2005 4:30:49 PM -0700 Paul Querna [EMAIL PROTECTED] wrote:
Then we should remove them from trunk today. Why leave a 'flat-out
wrong' API available?
If no one has removed them from trunk by the hackathon next weekend, I will
remove them then. -- justin
Now that Covalent has released it's ERS 3.0 distribution, mod_ftp is now
officially offered for donation/incubation/graduation to the ASF.
mod_ftp (previously Covalent FTP) is an Apache 2.0 Protocol Module which
implements FTP (RFCs 959, 1123, 2228, 2389), including such features
as FTP over
Jim Jagielski wrote:
Now that Covalent has released it's ERS 3.0 distribution, mod_ftp is now
officially offered for donation/incubation/graduation to the ASF.
mod_ftp (previously Covalent FTP) is an Apache 2.0 Protocol Module which
implements FTP (RFCs 959, 1123, 2228, 2389), including such
Have you checked
http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL
PROTECTED] ?
It contains a small patch which was not discussed any further here.
Regards
Rüdiger
Hansjoerg Pehofer wrote:
Hi,
it has been some time since the original thread.
This is in reply to
On Jul 7, 2005, at 3:19 PM, Sander Striker wrote:
Is there anything left for the community to work on? Or rather, do
you
think there is enough to do to attract a few (new) developers?
Yes, on both counts :)
Jim Jagielski wrote:
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.
I don't know if I get a vote, but it's
-1
This would have been an exciting project in 1989, but ftp
This is a code donation, using well-established ASF procedures,
in the interests of having that codebase become part of the ASF
HTTP Server Project, either bundled in with httpd or via
a subproject.
No idea what you mean by abandoned code nor support...
I would suggest you look into the
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.
+1. Having an integrated FTP server makes sense when Apache HTTPd is
measured up against IIS.
Jim Jagielski wrote:
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.
+1, I think this is a great addition to the httpd project, and would
love to help with the Incubation.
-Paul
On Jul 7, 2005, at 11:26 AM, Jim Jagielski wrote:
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.
+1
Brian
This was lazy concensus; I would prefer an up-down vote.
I can't picture a scenario where, if do not reach a single
module hook, we want the server to keep the connection open.
Comments/notes/votes please.
This happened to fix some ugly side effects of a previously
reported mod_ssl bug, but
At 01:33 PM 7/1/2005, William A. Rowe, Jr. wrote:
I have bumped the MODULE_MAGIC_COOKIE for 2.1.7. This will be
bumped again upon 2.2 release to AP22.
-#define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */
+#define MODULE_MAGIC_COOKIE 0x41503231UL /* AP21 */
The question remains, so please choose
At 11:27 PM 7/7/2005, William A. Rowe, Jr. wrote:
I corrected the ap_strtol result tests, based on the fact that
it's *our* strtol, and we know we will hiccup errno if we see
out of range, or no digits at all, and end_ptr is guarenteed
to be set.
I clicked send before save. This;
if (errno ||
One more thought on this thread; wouldn't it be nice to
communicate to mod_cache not to trust this flaky response
or request TE+CL combination? Unsetting the keep alive on
both the proxy and client adds some degree of saftey, but
marking this non-cachable would eliminate any likely hood
of cache
28 matches
Mail list logo
