httpd.conf lines for mbox
Would someone be kind enough to show me the lines in their httpd.conf file that deal with mod_mbox?
Re: Generated spool file okay to copy after parse?
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. Can I reasonable assume that it's okay to expose that spool file name to my script engine to allow code to copy that file to another location? Maybe :-). The internal behavior of the spool brigades is something we need to work on from the httpd-side, since they have slightly different needs. I want to see our spool buckets become a bit smarter: right now mod_apreq2 is creating multiple spool files when it could (in principle) consolidate them into a single file. The safest thing for you to do right now is to write copy the brigade to a separate file. You shouldn't peek inside the brigade to look at the bucket types yet; ideally we'll provide another utility function to intelligently write the spool brigade to a file (here's my +1 for a patch to apreq_util.[ch] that adds an apreq_brigade_copy_to_file function). BTW - the whole apreq_param_t and apreq_value_t code is pretty sweet. Glad you like it ;-) -- Joe Schaefer
Re: Philosophy, empty body still a request body?
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. Transfer-Encoding: chunked 0 Is not the same as no message body. both imply a body, with no body to follow. Nope. Both imply that the entity body is of zero length. Only the first one says there is no message body. Roy
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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 other transfer encodings? Wouldn't it be better to register a set of transfer encoding filters and then error if none matches? Oh, never mind, this is for 1.3. +0. Roy
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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 = ap_strtol(content_length, len_end, 10);
...
+if (errno || (c-len 0) || (len_end
*len_end)) {
You should copy the logic used on the trunk to get the correct
tests for
a strtol parse error:
errno || len_end == content_length || *len_end || c-len 0
The len_end == content_length just means that there was no digits
seen (possibly a blank)... not sure if we should consider that
an error.
An empty string, right: I think it's certainly correct to treat that as
invalid C-L header; indeed some strtol's themselves set errno for that
case. (the perl-framework C-L tests picked up this inconsistency a
while back)
That's why in all other places we've used the (len_end *len_end)
check, which ensures that
There is no case where strtol will set len_end = NULL so the first half
of the conditional is redundant. (also len_end was not NULL-initialized
so if it was an attempt to catch cases where strtol does *not* set
len_end, it was not correct ;)
it's valid *and* that it's seen an invalid char. ap_strtol( ...)
returns 0 but isn't an error (though in this context, I see your
point).
Re: mod_cache caching the 301 Moved Permanently
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 http://www.beach-clothing.com/where-to-buy/, but once cached mod_disk_cache delivers HTTP status 200 instead of 301 (but correctly redelivering the Location header). I have not proved this for myself so far, but this seems the problem to me. This wouldn't surprise me one bit. The 2.1 branch has seen quite a bit of churn in this area. Any chance you could give 2.1 a go and see if that works correctly? It is the same problem as described in issue 32226 [2]. Unfortunately, the described behavior is still present in both httpd 2.0.54 and 2.1.6-alpha with mod_disk_cache active. I can not reproduce it with 2.1.6-alpha and mod_mem_cache. Tested with the following setup: Frontend: httpd 2.1.6-alpha on 127.0.0.1, cache, disk_cache and proxy* modules loaded, out of the box httpd.conf plus: CacheRoot /cache/alpha CacheEnable disk / CacheDirLevels 1 CacheDirLength 2 ProxyPass/ http://backend.tld/ ProxyPassReverse / http://backend.tld/ Backend: Apache 1.3, a file cachetest/gonk/index.html relative to DocumentRoot. A first request to the Proxy (GET /cachetest/gonk) correctly responds in 301ing to /cachetest/gonk/ first -- and then getting the index document. There are 2 .data/.header couples in the cachedir at this point (the redirect-message and the index document ). A second request with a second client, or if the browser's cache has been cleared, returns the cached Moved Permanently message with status 200. This message contains a link in the backend's view of the URLs (as discussed in the original thread). The /cache/alpha/Kx/[EMAIL PROTECTED] Cache File contains: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@-a89Nû^C^@@Žô8C[EMAIL PROTECTED]89[EMAIL PROTECTED]89[EMAIL PROTECTED]/cachetest/gonk?Date: Thu, 07 Jul 2005 12:34 :21 GMT Server: Apache Location: http://127.0.0.1/cachetest/gonk/ Content-Type: text/html; charset=iso-8859-1 Expires: Thu, 07 Jul 2005 12:35:21 GMT Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-at,de;q=0.8,en;q=0.5,it;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Max-Forwards: 10 X-Forwarded-For: 127.0.0.1 X-Forwarded-Host: 127.0.0.1 X-Forwarded-Server: 127.0.0.1 [3], which is an attachment to [2] contains a fragment that keeps mod_cache.c from handling redirects at all -- if i understood it right, however it works for us. This is probably only the second best i approach, since 301 is cacheable. Regards, Hansjörg References: [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL PROTECTED] [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=32226 [3] http://issues.apache.org/bugzilla/attachment.cgi?id=13433 -- IT ServicesUniversity of Innsbruck CFB4 D6E7 33F4 34C0 18B9 6661 E355 4337 3F8B D9C2 http://purl.org/net/hansjoerg.pehofer/public_key signature.asc Description: Digital signature
Re: Apache 2.2 (was 1.3) Strict proxy C-L / T-E conformance
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 module know that the server doesn't support other transfer encodings? Wouldn't it be better to register a set of transfer encoding filters and then error if none matches? Oh, never mind, this is for 1.3. +0. To that idea, for Apache 2.2, a huge ++1! I'll ensure we are a bit more flexible for 2.1-dev. As I think about it, we are wasting cycles injecting a filter which keeps looking left and right to decide if it is handling a C-L body or a T-E body. IMHO these need to become two different filters, and the body filter would -only- be injected in the absence of all other T-E options. A registered T-E filter would stack (with 'chunked' at the lowest layer of the stack). The order of stacking remains the only puzzle to be solved. Bill
Re: Philosophy, empty body still a request body?
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: 0 Is the same as no message body. Ack. But combined with a T-E header, we are told to unset this Content-Length, so it must be unset when presented in combination with T-E:. Transfer-Encoding: chunked 0 Is not the same as no message body. Cool. Thank you for the clarification. Final question, please verify my guess that; Content-Length: is the same as Content-Length: 0
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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 back) This is also noted in the comments when we fixed the invalid c-l logic (overflow/underflow) some time ago. There is no case where strtol will set len_end = NULL so the first half of the conditional is redundant. (also len_end was not NULL-initialized so if it was an attempt to catch cases where strtol does *not* set len_end, it was not correct ;) 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 :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Sith happens - Yoda
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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 in output). But if Roy says it's invalid, then we need to do what's right :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Sith happens - Yoda
Re: Philosophy, empty body still a request body?
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 : 1*DIGIT the empty string does not match 1*DIGIT, so it's not a valid header. joe
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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, src/ap/ap_strtol.c, don't we provide our own strtol which we can trust? Bill
Re: [Patch 1.3] Strict proxy C-L / T-E conformance
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, just in case :) In httpd-1.3, src/ap/ap_strtol.c, don't we provide our own strtol which we can trust? Yep, we do. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Sith happens - Yoda
Re: Philosophy, empty body still a request body?
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 - 1*DIGIT means a sequence of 1 or more DIGIT characters. although LWS is obviously assumed by many clients. I'd suggest that is a grammar bug :) the implied *LWS rule is part of the grammar ;) joe
Re: svn commit: r208787 - in /httpd/httpd/trunk/modules: http/http_filters.c http/http_protocol.c proxy/mod_proxy.c
--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
[VOTE] mod_ftp for HTTP Server Project
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 SSL, jailing logged-in users, extended logging, firewall awareness and limiting logins. As Covalent FTP, it has been used by numerous well-known F500 companies, and is such a real-world protocol module, and not simply an academic exercise (this is not a comment on any other protocol modules in existence, but a statement to ensure that the module has been used and tested in real-world environments by major clients). The entire code-base, including Perl test scripts for inclusion in httpd-test, is available and ready for donation into the ASF svn repos. I volunteer as Champion. 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.
Re: [VOTE] mod_ftp for HTTP Server Project
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 features as FTP over SSL, jailing logged-in users, extended logging, firewall awareness and limiting logins. As Covalent FTP, it has been used by numerous well-known F500 companies, and is such a real-world protocol module, and not simply an academic exercise (this is not a comment on any other protocol modules in existence, but a statement to ensure that the module has been used and tested in real-world environments by major clients). The entire code-base, including Perl test scripts for inclusion in httpd-test, is available and ready for donation into the ASF svn repos. 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? Assuming the answer is yes: 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. Sander
Re: mod_cache caching the 301 Moved Permanently
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 [1].
Re: [VOTE] mod_ftp for HTTP Server Project
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 :)
Re: [VOTE] mod_ftp for HTTP Server Project
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 doesn't work well with today's internet.: today it's just a way to make systems that just don't work for people.
Re: [VOTE] mod_ftp for HTTP Server Project
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 Incubator Project, which is how we import external codebases and build a community around them. On Jul 7, 2005, at 4:37 PM, [EMAIL PROTECTED] wrote: Is this just a code dump... or are the Covalent authors promising to support it and help adapt it to ( Non-Covalent Apache ) needs? There's already an awful lot of Covalent sponsored code in Apache 2.0 that was 'abandoned' by the original authors. I believe any code submission to Apache requires at least some clarification about support. Kevin Kiley In a message dated 7/7/2005 2:49:51 PM Central Daylight Time, [EMAIL PROTECTED] writes: 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 :)
Re: [VOTE] mod_ftp for HTTP Server Project
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.
Re: [VOTE] mod_ftp for HTTP Server Project
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
Re: [VOTE] mod_ftp for HTTP Server Project
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
[vote] svn commit: r191517
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 that's only a secondary motivation.
If we concur this is goodness, I'll port to 2.1, then 2.0.
Bill
At 12:27 PM 6/20/2005, [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Mon Jun 20 10:27:48 2005
New Revision: 191517
URL: http://svn.apache.org/viewcvs?rev=191517view=rev
Log:
These failure cases are all essentially bogus submissions to httpd,
do not persist the connection if the client can't formulate any
respectible request (e.g. likely to be exploit testing).
[None of the modified failure cases occur prior to request processing.]
Modified:
httpd/httpd/branches/1.3.x/src/main/http_protocol.c
Modified: httpd/httpd/branches/1.3.x/src/main/http_protocol.c
URL:
http://svn.apache.org/viewcvs/httpd/httpd/branches/1.3.x/src/main/http_protocol.c?rev=191517r1=191516r2=191517view=diff
==
--- httpd/httpd/branches/1.3.x/src/main/http_protocol.c (original)
+++ httpd/httpd/branches/1.3.x/src/main/http_protocol.c Mon Jun 20 10:27:48
2005
@@ -1186,6 +1186,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: URI too long);
+r-connection-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1194,6 +1195,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: erroneous characters after protocol
string: %s,
ap_escape_logitem(r-pool, r-the_request));
+r-connection-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1207,6 +1209,7 @@
if (r-status != HTTP_REQUEST_TIME_OUT) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: error reading the headers);
+r-connection-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1260,6 +1263,7 @@
(see RFC2616 section 14.23): %s, r-uri);
}
if (r-status != HTTP_OK) {
+r-connection-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
[vote] MODULE_MAGIC_COOKIE
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 one; [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2 [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2 [ ] Get it over with already and bump now to AP22 for httpd-2.1 Bill
Re: [vote(s)] [Patch 1.3] Strict proxy C-L / T-E conformance
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 || (c-len 0) || (len_end *len_end)) {
will be committed as:
if (errno || *len_end || (c-len 0)) {
This is truly all we need to test.
Re: 2.1.5 available for testing
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 poisoning.
I don't have the code, perhaps someone can point out an easy
answer for 2.0/2.1 or offer a patch to mod_cache to make that
toggleable. In 1.3, this patch is trivial.
Just a thought,
Bill
At 05:45 AM 6/23/2005, Jeff Trawick wrote:
On 6/23/05, jean-frederic clere [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
++1 To Joe's comments.
Jeff's fix is technically right, but scares the nibbles out
of me. If, for example, an exploit is able to inject the
T-E on top of the legit C-L, I really suspect we should not
trust the origin server at all.
One important situation to fear is a buggy server or proxy+server that
we may not be able to talk to at all if we are extremely strict.
[As you implied w.r.t. Apache 1.3] The smuggling fear is really if we
allow keepalive on this connection to the origin server again. We
could be confused by making the wrong choice from {CL, TE} and
misunderstand the next response. We can set backend-close and
origin-keepalive to prevent that.
If we don't allow keepalive, then it is down to whether or not this
single request can be parsed correctly if our choice of {CL, TE} makes
sense.
For origin servers (as opposed to clients) make this choice
between ignore C-L, or fail, configurable?
try very hard to make a reasonable choice with no configuration :)
(speaking to the choir, of course)
My observation is that there are far more varied clients in
the world than servers, each with unique faults. But the
RFC 2616 is clear...
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
...and server authors can be expected to be less buggy than clients.
Permissive in what we accept, strict in what we send implies some
strictness in what we trust to pass on to the client.
We're removing the protocol breakage in what we pass on to the client.
At this point, we either send a valid response or it is if the server
dropped the connection before sending the full response.
(I hear what you're screaming. I think the minimal-intervention path
should be preferred if we can justify it.)
So +.5 to Jeff's patch, and let's discuss if the proxy response should
then be trusted at all with T-E and C-L, in httpd-2.x where we support
keepalives.
Once the patch applied we lose the information that the request was
incorrect.
That means we won't be able to choose in proxy between sending C-L (and
dechunk)
and T-E.
I don't follow here. How does the backend choice of {TE, CL} affect
what we send the client?
