new webaccel appliance - new question
Hi, Regarding this new webaccel project (hardware appliance) I was wondering about some points: - Use Freebsd S.O - Tuning kernel and let it as small as possible. - Enable Sendfile; - Use AcceptFilter and accf_http - --enable-nonportable-atomic=yes (http://httpd.apache.org/docs/1.3/misc/perf-bsd44.html) (trying to use it in 2.2). - mod_cache, mod_proxy and mod_deflate. - filesystem tuning (inode size, async mounting ? ); - tcp/ip sysctl tuning; The main goal is not to have a portable system because we'll use a dedicated hardware, but make the system as fast as possible. I'm searching for another points to optimize freebsd, tcp/ip stack and apache. There are some discussions about window_scaling, tcp buffers, etc. What do you think about? Best Regards, Fernando
Re: new webaccel appliance
Well, There is no problem to let apache do its response with Vary header. It was strange to me apache has two versions of the same object in the cache. As explained earlier this might happen because MSIE introduces a white-space after comma in the Accept-Encoding header. (maybe an apache parse mistake). Best Regards, Fernando - Original Message - From: "Andreas Kotes" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 18, 2007 6:56 PM Subject: Re: new webaccel appliance Hello, * Fernando - Dfcom <[EMAIL PROTECTED]> [20070918 22:06]: In RFC 2616 I found: An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation I don't know if removing Vary header is rfc-compliant, but resolves the problem. What do you think about? I think stripping the Vary header would be terribly wrong, and apache should follow RFC 2616 13.6 more thoroughly, i.e.: "The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2." so, the 'special case' for matching Roy recommends to introduce is actually sanctioned by the RFC, if not even recommended/required by it. my 2 cents, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: 17/9/2007 13:29
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: > William A. Rowe, Jr. wrote: >> >> The other aspect, if a zlib1.dll replacement is needed for some critical >> decryption flaw in zlib again, it will be nice not to force users to >> entirely replace openssl or mod_deflate. So I expect we'll leave it >> as-is. >> > I think mod_deflate on Windows links statically (zlib.lib) while openssl > is linked dynamically (zdll.lib). At 40-60kb it's no big deal either > way - but the "security flaw in zlib" argument would seem to apply to > both equally. Both static or both dynamic would be more consistent. This was 2.0 that compiled in the subset of zlib sources directly. 2.2 should (and I'll fix this if I'm wrong) be linked to zlib1.dll
Re: Thoughts on Camillia in openssl binaries?
William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the "security flaw in zlib" argument would seem to apply to both equally. Both static or both dynamic would be more consistent. -tom-
Re: new webaccel appliance
Hello, * Fernando - Dfcom <[EMAIL PROTECTED]> [20070918 22:06]: > In RFC 2616 I found: > > An HTTP/1.1 server SHOULD include a Vary header field with any > cacheable response that is subject to server-driven negotiation > > I don't know if removing Vary header is rfc-compliant, but resolves the > problem. > > What do you think about? I think stripping the Vary header would be terribly wrong, and apache should follow RFC 2616 13.6 more thoroughly, i.e.: "The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2." so, the 'special case' for matching Roy recommends to introduce is actually sanctioned by the RFC, if not even recommended/required by it. my 2 cents, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: > William A. Rowe, Jr. wrote: >> Two questions, one technical one legal. >> >> Technically, do we want to enable the Camillia algorithms in our >> binary builds of openssl 0.9.8 for win32 and other platforms where >> we might build it? >> >> Legally are we satisfied by >> http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html >> ? There is a small clause about permission needed to export from >> JP, which would mean if a JP site redistributed our binary (e.g. >> reexported it) it might cause them a hassle. >> >> Bill >> > Seems reasonable in anticipation of it becoming supported in FireFox 3. Yes, that seems like a measurable target. It's nice to be ahead of the curve. > FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows > to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. > The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. Good to know, thanks! > On a slightly-related note; it might also be a good change to statically > link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds > about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. Are you factoring in the cost of statically linking it also to mod_deflate? Consider also anyone using either the compression or decompression side of zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment of awk.exe for the installer that I'm pretty intolerant of bloat, > I think rle compression (which is always available) or no-compression > gets used for SSL in most cases anyway. Many Windows users delete > zlib1.dll and never notice its absence. Well people who randomly delete dll's certainly get what they ask for, we install it in the httpd/bin tree, not on their system32 or somewhere equally offensive. But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. > PERL Configure VC-WIN32 enable-camellia zlib > --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib FYI the ASF's build hard-links it this way (zdll.lib instead) which ensures we throw away the zlib-dynamic stubs (and eliminate some race and processing-time performance hits), so there is that factor, too. I sort of doubt we'll see any savings when you factor deflate and openssl together? The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is.
Re: new webaccel appliance
I did a test here removing the Vary header from apache response. Header unset Vary I run some tests with apache all requests/responses were http/1.1 - keepalive, compression, etc And mod_cache stored just one copy of files. Firefox and MSIE 6/7 didn't show any problem. In RFC 2616 I found: An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation I don't know if removing Vary header is rfc-compliant, but resolves the problem. What do you think about? Fernando - Original Message - From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 18, 2007 4:46 PM Subject: Re: new webaccel appliance
Re: Thoughts on Camillia in openssl binaries?
William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib -tom-
Re: new webaccel appliance
On tis, 2007-09-18 at 19:40 +0200, Roy T.Fielding wrote: > Argued? The space does not change the value of the field (which is > a comma-separated list). The question is really up to us as to how > much effort we make to compare the values for equality, since the > non-match just makes our cache slow and bulky. Given the number > of those browsers, we should special-case this comparison. And there is also RFC2616 13.6 Caching Negotiated Responses which tells you to use If-None-Match to avoid fetching multiple copies only because of slight variations in Vary indicated request headers.. Regards Henrik signature.asc Description: This is a digitally signed message part
hook - pre_request
Hi,
I need a hook function that looks at pre_request (also post) phase
after the rewriting phase of worker's URL (e.g.,
http://worker2.com/test.php) to use the name of the worker for my own
propose.
I tried to put this way:
static const char * const aszPre[]={ "mod_proxy_balancer.c", NULL };
proxy_hook_pre_request(my_pre_request, aszPre, NULL, APR_HOOK_LAST);
But the proxy_pre_request function in mod_proxy_balance returns OK,
and my function is nerver called. There's a better way to do this
without touching in apache internal source-code?
Putting in more details... look at this log information:
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_balancer.c(42): proxy:
BALANCER: canonicalising URL //mycluster/
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_balancer.c(274): proxy:
BALANCER: Found value (null) for stickysession BALANCEID
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_balancer.c(962): proxy:
Entering byrequests for BALANCER (balancer://mycluster)
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_balancer.c(533): proxy:
BALANCER (balancer://mycluster) worker (http://putiri.ic.uff.br)
rewritten to http://putiri.ic.uff.br/
*** (I NEED A HOOK HERE)
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy.c(819): Running scheme
balancer handler (attempt 0)
*** (OR HERE ... ?)
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_http.c(1693): proxy:
HTTP: serving URL http://putiri.ic.uff.br/
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(1852): proxy: HTTP:
has acquired connection for (putiri.ic.uff.br)
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(1913): proxy:
connecting http://putiri.ic.uff.br/ to putiri.ic.uff.br:80
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(2012): proxy:
connected / to putiri.ic.uff.br:80
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(2169): proxy: HTTP:
fam 2 socket created to connect to putiri.ic.uff.br
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(2266): proxy: HTTP:
connection complete to 200.20.15.226:80 (putiri.ic.uff.br)
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_http.c(1478): proxy:
start body send
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_http.c(1567): proxy: end body send
[Thu Sep 13 18:15:58 2007] [debug] proxy_util.c(1870): proxy: HTTP:
has released connection for (putiri.ic.uff.br)
[Thu Sep 13 18:15:58 2007] [debug] mod_proxy_balancer.c(561):
proxy_balancer_post_request for (balancer://mycluster)
*** (ALSO I NEED A POST HOOK HERE, i think this is easier... )
Thanks in advance.
--
Vinicius Tavares Petrucci
home page: http://www.ic.uff.br/~vpetrucci
--
Vinicius Tavares Petrucci
home page: http://www.ic.uff.br/~vpetrucci
Re: new webaccel appliance
On Sep 18, 2007, at 6:46 PM, Plüm, Rüdiger, VF-Group wrote: This works "as designed". Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Argued? The space does not change the value of the field (which is a comma-separated list). The question is really up to us as to how much effort we make to compare the values for equality, since the non-match just makes our cache slow and bulky. Given the number of those browsers, we should special-case this comparison. Roy
AW: new webaccel appliance
> -Ursprüngliche Nachricht- > Von: Fernando - Dfcom > Gesendet: Dienstag, 18. September 2007 16:18 > An: dev@httpd.apache.org > Betreff: new webaccel appliance > > > > debian:/cache# grep 'fd.jpg?' * -r > Binary file > 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MO > eRbRg.header > matches > Binary file > 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK > 1JffA.header > matches > > > debian:/cache# cat > 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MO > eRbRg.header > È"¤õ_:Þt:)ÍÀf: > &ÕÀf:http://teste.com.br:80/img/fd.jpg?Date: > Tue, 18 Sep 2007 > 02:48:34 GMT > Server: Apache > Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT > ETag: "dd09a4-1aa-a904ef00" > Accept-Ranges: bytes > Content-Type: image/jpeg > Via: 1.1 teste.com.br > Vary: Accept-Encoding > Content-Encoding: gzip > > Host: www.rodadaalimentos.com.br > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; > rv:1.8.1.5) > Gecko/20070713 Firefox/2.0.0.5 > Accept: image/png,*/*;q=0.5 > Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Referer: http://www.rodadaalimentos.com.br/estilos.css > Max-Forwards: 10 > Via: 1.1 teste.com.br > X-Forwarded-For: 201.81.185.230 > X-Forwarded-Host: www.rodadaalimentos.com.br > X-Forwarded-Server: teste.com.br > > > debian:/cache# cat > 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK > 1JffA.header > È"@Ééð_:@)Át:H²µ¼f:¼¼¼f:http://teste.com.br:80/img/fd.jpg?Date > : Tue, 18 Sep > 2007 02:47:25 GMT > Server: Apache > Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT > ETag: "dd09a4-1aa-a904ef00" > Accept-Ranges: bytes > Content-Type: image/jpeg > Via: 1.1 teste.com.br > Vary: Accept-Encoding > Content-Encoding: gzip > > Accept: */* > Referer: http://www.rodadaalimentos.com.br/inscritos.html > Accept-Language: pt-br > Accept-Encoding: gzip, deflate > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) > Host: www.rodadaalimentos.com.br > Max-Forwards: 10 > Via: 1.1 teste.com.br > X-Forwarded-For: 201.81.185.230 > X-Forwarded-Host: www.rodadaalimentos.com.br > X-Forwarded-Server: teste.com.br This works "as designed". Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Regards Rüdiger
Thoughts on Camillia in openssl binaries?
Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill
new webaccel appliance
Hi, I'm developing a webaccel project and I am trying to use apache to do that. I'm choosing apache because squid does not support natively http/1.1 compression. The main resources are: security (mod_security), saving bandwidth (mod_deflate) and lowering backend servers load (mod_proxy/mod_disk_cache). My testing environment is: one backend server, one webaccel server, two windows workstation (1- firefox and 1- MSIE 6.x). All steps were right (proxy, cache and deflate) but apache cached two copies of all objects for every site I access- one for firefox and one for MSIE (I checked this on headers stored in the cache directory)- When using other version of MSIE (7.x) no more copies were done. Is this a common apache (mod_cache) behaviour ? Does squid has this same content negotiation ? debian:/cache# grep 'fd.jpg?' * -r Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MOeRbRg.header matches Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK1JffA.header matches debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MOeRbRg.header È"¤õ_:Þt:)ÍÀf: &ÕÀf:http://teste.com.br:80/img/fd.jpg?Date: Tue, 18 Sep 2007 02:48:34 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: "dd09a4-1aa-a904ef00" Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Host: www.rodadaalimentos.com.br User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Accept: image/png,*/*;q=0.5 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Referer: http://www.rodadaalimentos.com.br/estilos.css Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK1JffA.header È"@Ééð_:@)Át:H²µ¼f:¼¼¼f:http://teste.com.br:80/img/fd.jpg?Date: Tue, 18 Sep 2007 02:47:25 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: "dd09a4-1aa-a904ef00" Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Accept: */* Referer: http://www.rodadaalimentos.com.br/inscritos.html Accept-Language: pt-br Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: www.rodadaalimentos.com.br Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br Best Regards, Fernando
Re: [PATCH 43415] Logging remote port.
On Tue, 18 Sep 2007 14:04:32 +0200 Adam Hasselbalch Hansen <[EMAIL PROTECTED]> wrote: > You can read the entire thing in Danish here: > > http://www.folketinget.dk/samling/20061/Lovforslag/L63/Bilag/7/351262.PDF Looks more like legislation for ISPs than folks with a webserver. > The relevant part is Section 5, which says (losely translated): > > § 5. A provider of electronic communication nets or services for end > users must register the following information about an internet > session's initiating and terminating package: The word "session" doesn't sit easily with a stateless protocol (HTTP), and neither does the information required: > 6. Time of start and end of communication. ... which tends to suggest they really do mean sessions. I'd be sceptical about that applying to non-sessions such as HTTP requests. § 5 Part 2: [user's identity & contact details]. Yeah, right. Part 3: [applies to mobile access] Part 4: [Requirements don't apply if they're not technically possible to meet] So if Apache doesn't support this, you're exempt, yesno? :-) I was kind-of wondering whether anyone's thinking in terms of fingerprinting botnet/malware attacks rather more than tracing death-threats or naughty pictures back to the last anonymiser or zombie in their path. If governments are doing that, it'll just induce botnets to randomise a bit more, or mimic patterns of legitimate users. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [PATCH 43415] Logging remote port.
Nick Kew wrote: On Tue, 18 Sep 2007 12:25:18 +0200 Adam Hasselbalch Hansen <[EMAIL PROTECTED]> wrote: I have created a patch for httpd 2.2.6, giving the additional LogFormat directive %R, which logs the port of the host making the request. This is due to new legislation in Denmark, requiring ISPs and hosting companies to log the originating port of all traffic. Is there a reference for that legislation, and whatever debate there was surrounding it? As in, what do they expect to gain from it? Debate? It's the Justice Department that's had a brainfart, that's what's happened. Apparently it's meant to ease criminal investigations involving electronic communication (read: terror investigations). But it's totally meaningless, since public terminals (like in an Internet Cafe) are exempt from the law. You can read the entire thing in Danish here: http://www.folketinget.dk/samling/20061/Lovforslag/L63/Bilag/7/351262.PDF The relevant part is Section 5, which says (losely translated): § 5. A provider of electronic communication nets or services for end users must register the following information about an internet session's initiating and terminating package: 1. Originating Internet Protocol address 2. Recipient Internet Protocol address 3. Transport protocol 4. Originating port number 5. Recipient port number 6. Time of start and end of communication. Looks harmless, and evidently adds value for you. Well, value, schmalue. But it's the law...
Re: [PATCH 43415] Logging remote port.
On Tue, 18 Sep 2007 12:25:18 +0200 Adam Hasselbalch Hansen <[EMAIL PROTECTED]> wrote: > I have created a patch for httpd 2.2.6, giving the additional > LogFormat directive %R, which logs the port of the host making the > request. > > This is due to new legislation in Denmark, requiring ISPs and hosting > companies to log the originating port of all traffic. Is there a reference for that legislation, and whatever debate there was surrounding it? As in, what do they expect to gain from it? > Any feedback is appreciated :) Looks harmless, and evidently adds value for you. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [PATCH 43415] Logging remote port.
> -Ursprüngliche Nachricht-
> Von: Adam Hasselbalch Hansen
> Gesendet: Dienstag, 18. September 2007 12:25
> An: dev@httpd.apache.org
> Betreff: [PATCH 43415] Logging remote port.
>
>
> I have created a patch for httpd 2.2.6, giving the additional
> LogFormat
> directive %R, which logs the port of the host making the request.
>
> This is due to new legislation in Denmark, requiring ISPs and hosting
> companies to log the originating port of all traffic.
5 comments:
1. Please provide a patch against trunk.
2. Please also add a patch for the documentation.
3. I am not too happy with using %R, but to be honest I have no better proposal
:-).
Maybe other have.
4.
Instead of using
+static const char *log_remote_port(request_rec *r, char *a)
+{
+ return apr_psprintf(r->pool, "%u", r->connection->remote_addr->port);
+}
I would prefer
+static const char *log_remote_port(request_rec *r, char *a)
+{
+ return pfmt(r->pool, (int) (r->connection->remote_addr->port));
+}
like used for log_status.
5. Thanks for your patch :-).
Regards
Rüdiger
Re: Broken URI-unescaping
On Tue, 18 Sep 2007 15:01:33 +0530 rahul <[EMAIL PROTECTED]> wrote: > Hi, > [Nick Kew:] > ... > | PR#35256 (which I was on the point of entering anew when I > | found it). The simple patch to 35256 fixes the specific > | instance of un-breaking AllowEncodedSlashes, but what proxy > | could use is to be able to generalise that: maybe > | AllowEncodedChars [whatever]. > Do you mean > AllowEncodedChars On|Off > or more like > AllowEncodedChars "/=\" > > I have been looking at that bug, and can update the patch for either > if required. The latter. I was planning to fix it myself, but if you get a round tuit first, I won't complain :-) -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
[PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional LogFormat directive %R, which logs the port of the host making the request. This is due to new legislation in Denmark, requiring ISPs and hosting companies to log the originating port of all traffic. Any feedback is appreciated :) Thanks, Adam
Re: Broken URI-unescaping
Hi, [Nick Kew:] ... | PR#35256 (which I was on the point of entering anew when I | found it). The simple patch to 35256 fixes the specific | instance of un-breaking AllowEncodedSlashes, but what proxy | could use is to be able to generalise that: maybe | AllowEncodedChars [whatever]. Do you mean AllowEncodedChars On|Off or more like AllowEncodedChars "/=\" I have been looking at that bug, and can update the patch for either if required. | There's a related class of issues concerning URLs and charset, | in PR#18805 and PR#32730. This could probably be hacked around | by pre-processing URLs in a post_read_request hook, but it would | seem cleaner to tackle it when we run ap_unescape_url. | | I wonder if there's a case for an unescape_url hook, or for the | existing unescape_url to be punted to a post_read_request function? ps: sorry for the late mail, my earlier mail got shot down by ezlm. rahul -- 1. e4 _
Re: [Bug 43386] - Default handler produces wrong content length when replacing file
Hello,
| --- Additional Comments From [EMAIL PROTECTED] 2007-09-17 04:36 ---
| rahul, the httpd project has acknowledged the race for the past seven or more
| years, but there is simply nothing to be done about it.
| We are likely to move to, as you suggest, stat'ing the fd and not trusting
| the resource-by-name in the next iteration of httpd (e.g. 2.4 or 3.0). But
| there will *still* be a race if the file is truncated during the send.
| As Joe suggests, if you are modifying your content on the fly, you will
| encounter side effects (always). The only issue are the specific side effects
| based on how you are manipulating that content and how many extra steps httpd
| performs to work around you.
My contention is that there are two separately addressable issues here.
1) Where the user is directly modifying the file in question. Since
there is nothing that we can do about this, This is discouraged, and a
race will always be there if the user does this.
2) Where the user is trying to replace a particular file in his doc-root
with out taking down the httpd process. (This is in-fact the solution
suggested by Joe: ("write content to temporary file; rename file into place")
The race is in the solution and the bug reported is exactly that, (and it is an
avoidable condition as the patch shows - though not efficient). More over, it
is some thing that can happen often as there is no other way to replace a file
with another with out taking down the process.
Note that we are not 'modifying the content on the fly' since no
modification of the said file content has happened.
I will close the bug if you still think that it is invalid, but I think
it ought to be in 'later' with PatchAvailable.
(ps: this is a resend since the earlier mail seems not to have made it.)
rahul
--
1. e4 _
