You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Adam Hasselbalch Hansen <ah...@one.com> on 2007/09/18 12:25:18 UTC
[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: [PATCH 43415] Logging remote port.
Posted by Oden Eriksson <oe...@mandriva.com>.
tisdagen den 18 september 2007 skrev Adam Hasselbalch Hansen:
> 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 :)
FYI: This has been applied for the upcoming Mandriva 2008 release, thanks.
--
Regards // Oden Eriksson
Re: [PATCH 43415] Logging remote port.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Magnus Bodin wrote:
>
> A standalone sniffing box should be the best solution to this, I guess.
> That does NOT store the content.
Ideally, until you note that if this machine is the SSL endpoint it's the
only one with any privilage to put 2+2 together. Both a good and bad
thing depending on what you are trying to accomplish.
No problem with the patch (I too found %R sort of funky but... what else?)
> This is insane.
We don't disagree :)
Re: [PATCH 43415] Logging remote port.
Posted by Magnus Bodin <ma...@bodin.org>.
On Tue, Sep 18, 2007 at 02:04:32PM +0200, Adam Hasselbalch Hansen wrote:
>
> § 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...
I live in Sweden, and I really, really hope we never see the same thing here.
But the point: Why implement this in e.g. Apache, when it is the ISP
responsibility to store this information for all "internet-sessions" initiating
and terminating package.
This should be implemented in the firewall/router instead of on
application level.
A standalone sniffing box should be the best solution to this, I guess.
That does NOT store the content.
This is insane.
-- magnus
Re: [PATCH 43415] Logging remote port.
Posted by Adam Hasselbalch Hansen <ah...@one.com>.
Nick Kew wrote:
> Looks more like legislation for ISPs than folks with a webserver.
ISPs and hosting companies alike.
> I'd be sceptical about that applying to non-sessions such as
> HTTP requests.
I think that semantics are lost on these people.
> 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? :-)
No, that's the beauty of it. If it is not technically possible to log
stuff, then you "just" have to log every 500 packets instead. Go figure....
/Adam
Re: [PATCH 43415] Logging remote port.
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 18 Sep 2007 14:04:32 +0200
Adam Hasselbalch Hansen <ah...@one.com> 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.
Posted by Adam Hasselbalch Hansen <ah...@one.com>.
Nick Kew wrote:
> On Tue, 18 Sep 2007 12:25:18 +0200
> Adam Hasselbalch Hansen <ah...@one.com> 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.
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 18 Sep 2007 12:25:18 +0200
Adam Hasselbalch Hansen <ah...@one.com> 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.
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/24/2007 10:55 PM, Jeff Trawick wrote:
> On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
>
>> 1. I would use strcasecmp instead of strcmp to avoid case issues in the config.
>
> sure; FWIW, some other format string comparisons are not case
> insignificant, but those can be checked for in the fullness of time
Thanks for the pointer. I checked it and AFAICT the situation is as follows:
1. Access to headers, notes and env variables is case insensitve as apr_tables keys
are case insensitive.
2. Cookie logging is case sensitive and IMHO needs to be as I think that case matters
for cookie names.
3. Time formating is case sensitive and needs to be.
4. Process id / Thread id logging is case sensitive and very similar to the port case
here, but I see no reason for it being case sensitive.
So I think we should handle similar situations the same. So if you exchange strcmp
in your patch with strcasecmp we should do the same afterwards for the process id case
(I can do this). If we want to stick with strcmp in the process id case we should stick
with strcmp in the port case.
Regards
Rüdiger
Re: [PATCH 43415] Logging remote port.
Posted by Jeff Trawick <tr...@gmail.com>.
On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 09/24/2007 02:04 PM, Jeff Trawick wrote:
> > On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
> >>
> >> On 09/23/2007 10:49 PM, Jeff Trawick wrote:
> >>> On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
> >>>>> -----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:
> >>>> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
> >>>> Maybe other have.
> >>> %{canonical}p (default)
> >>> %{local}p
> >>> %{remote}p
> >> Sounds good to me.
> >
> > The attached patch works for me (though I haven't yet rebuilt the docs
> > to see what that looks like).
>
> Patch looks good to me (including docs, which I rebuilt in my working copy),
> but as most of the time some comments :-).
thanks, of course!
> 1. I would use strcasecmp instead of strcmp to avoid case issues in the config.
sure; FWIW, some other format string comparisons are not case
insignificant, but those can be checked for in the fullness of time
> 2. We can save a few cycles by using apr_itoa instead of pfmt as IMHO port is never
> <= 0.
>
> BTW: I think format_integer should be removed as it is only used by pfmt. It can be replaced
> with apr_itoa. Just did this in r578927.
sure; I recall you mentioning apr_itoa() on this thread but I guess I forgot
I'll fix up before long.
Have fun!
Re: [PATCH 43415] Logging remote port.
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/24/2007 02:04 PM, Jeff Trawick wrote:
> On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
>>
>> On 09/23/2007 10:49 PM, Jeff Trawick wrote:
>>> On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
>>>>> -----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:
>>>> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
>>>> Maybe other have.
>>> %{canonical}p (default)
>>> %{local}p
>>> %{remote}p
>> Sounds good to me.
>
> The attached patch works for me (though I haven't yet rebuilt the docs
> to see what that looks like).
Patch looks good to me (including docs, which I rebuilt in my working copy),
but as most of the time some comments :-).
1. I would use strcasecmp instead of strcmp to avoid case issues in the config.
2. We can save a few cycles by using apr_itoa instead of pfmt as IMHO port is never
<= 0.
BTW: I think format_integer should be removed as it is only used by pfmt. It can be replaced
with apr_itoa. Just did this in r578927.
Regards
Rüdiger
Re: [users@httpd] Apache in embedded product
Posted by Krist van Besien <kr...@gmail.com>.
On 9/25/07, Malluru, Puri <Pu...@polycom.com> wrote:
> I tried that. I see Apache accepting connections and spitting the file I
> requested on telnet port. Below is session output. I tried this from a
> separate Linux box. Not even localhost. I don't understand why curl and
> wget is failing, but telnet is working fine.
Did you try a curl -v <url> ?
Can you send us the output of that?
Krist
--
krist.vanbesien@gmail.com
Bremgarten b. Bern, Switzerland
--
A: It reverses the normal flow of conversation.
Q: What's wrong with top-posting?
A: Top-posting.
Q: What's the biggest scourge on plain text email discussions?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Apache in embedded product
Posted by "Malluru, Puri" <Pu...@polycom.com>.
I tried that. I see Apache accepting connections and spitting the file I
requested on telnet port. Below is session output. I tried this from a
separate Linux box. Not even localhost. I don't understand why curl and
wget is failing, but telnet is working fine.
++++++++++++++++++++++++++++++++++++++++++
/home/pmalluru/work/webdownload/puritruman> telnet puritruman 9090
Trying 172.26.48.138...
Connected to puritruman.austin.polycom.com (172.26.48.138).
Escape character is '^]'.
GET /docs/2.2/style/css/manual-print.css HTTP/1.1
Host: puritruman:9091
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7)
Gecko/20070914 Firefox/2.0.0.7
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://puritruman:9091/docs/2.2/
HTTP/1.1 200 OK
Date: Tue, 25 Sep 2007 16:52:22 GMT
Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8a
Last-Modified: Thu, 17 Aug 2006 19:42:12 GMT
ETag: "51d806b-3390-d70fcd00"
Accept-Ranges: bytes
Content-Length: 13200
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/css
/*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* manual.css for printers
*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
/* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version
2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* mainframe ;-)
*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
html {
font-size: 11pt;
}...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++
-----Original Message-----
From: Krist van Besien [mailto:krist.vanbesien@gmail.com]
Sent: Tuesday, September 25, 2007 3:27 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Apache in embedded product
On 9/25/07, Malluru, Puri <Pu...@polycom.com> wrote:
> /home/pmalluru/work> curl -I http://puritruman:9090/
>
> /home/pmalluru/work>
> ++++++++++++++++++++++++++++++++++++++++++++++
> I pressed Ctrl+C to kill curl session above.
> I don't see an entry in access_log or in error_log for 9090 access.
Are you sure that there is nothing on your apache box, or between you
and your apache box that is blocking port 9090?
what do yo uget when you try curl -l http://localhost:9090 on the box
itself. (If you don't have curl on the embedded box, you can always
try a telnet localhost 9090)
Krist
--
krist.vanbesien@gmail.com
Bremgarten b. Bern, Switzerland
--
A: It reverses the normal flow of conversation.
Q: What's wrong with top-posting?
A: Top-posting.
Q: What's the biggest scourge on plain text email discussions?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache in embedded product
Posted by Krist van Besien <kr...@gmail.com>.
On 9/25/07, Malluru, Puri <Pu...@polycom.com> wrote:
> /home/pmalluru/work> curl -I http://puritruman:9090/
>
> /home/pmalluru/work>
> ++++++++++++++++++++++++++++++++++++++++++++++
> I pressed Ctrl+C to kill curl session above.
> I don't see an entry in access_log or in error_log for 9090 access.
Are you sure that there is nothing on your apache box, or between you
and your apache box that is blocking port 9090?
what do yo uget when you try curl -l http://localhost:9090 on the box
itself. (If you don't have curl on the embedded box, you can always
try a telnet localhost 9090)
Krist
--
krist.vanbesien@gmail.com
Bremgarten b. Bern, Switzerland
--
A: It reverses the normal flow of conversation.
Q: What's wrong with top-posting?
A: Top-posting.
Q: What's the biggest scourge on plain text email discussions?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Apache in embedded product
Posted by "Malluru, Puri" <Pu...@polycom.com>.
I did what you suggested. Below is my shell session contents.
+++++++++++++++++++++++++++++++++++++++
/home/pmalluru/work> curl -k -I https://puritruman:9091/
HTTP/1.1 200 OK
Date: Mon, 24 Sep 2007 22:27:17 GMT
Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8a
Last-Modified: Fri, 07 Sep 2007 14:06:23 GMT
ETag: "51d8080-1e2a-24d535c0"
Accept-Ranges: bytes
Content-Length: 7722
Content-Type: text/html
/home/pmalluru/work> curl -I http://puritruman:9090/
/home/pmalluru/work>
++++++++++++++++++++++++++++++++++++++++++++++
I pressed Ctrl+C to kill curl session above.
I don't see an entry in access_log or in error_log for 9090 access.
Then I logged in to embedded box to make sure apache is listening on
port 9090.
Below is out of "netstat -l"
+++++++++++++++++++++++++++++++++++++
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 0 *:login *:*
LISTEN
tcp 0 0 *:shell *:*
LISTEN
tcp 0 0 *:webcache *:*
LISTEN
tcp 0 0 *:tproxy *:*
LISTEN
tcp 0 0 *:7070 *:*
LISTEN
tcp 0 0 *:9090 *:*
LISTEN
tcp 0 0 *:9091 *:*
LISTEN
tcp 0 0 *:telnet *:*
LISTEN
tcp 0 0 *:polycom_api *:*
LISTEN
udp 0 0 *:792 *:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
++++++++++++++++++++++++++++++++++++++
Thanks
-----Original Message-----
From: Sander Temme [mailto:sctemme@apache.org]
Sent: Monday, September 24, 2007 5:23 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Apache in embedded product
On Sep 24, 2007, at 3:09 PM, Malluru, Puri wrote:
> I found Apache serving https just fine. When I try to access the same
> site with http, IE just waits forever.
>
> Please note that this whole build folder is mounted as nfs folder to
> embedded codec before starting apache.
>
> Am I missing any gotchas?
Yeah, don't use IE.
I'm serious. IE is fine for browsing web sites, but for testing your
configuration you'd be much better off with a tool that tells you
what's going wrong. For instance
curl -I http://yourbox:9090/ should give you a header back
curl -kI https://yourbox:9091/ should give you a header back, or a
connection error, or an openssl error, or...
So, the two million dollar questions:
1) What error does your client give you, and at which level?
2) What Does The Apache Error Log Say?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache in embedded product
Posted by Sander Temme <sc...@apache.org>.
On Sep 24, 2007, at 3:09 PM, Malluru, Puri wrote:
> I found Apache serving https just fine. When I try to access the same
> site with http, IE just waits forever.
>
> Please note that this whole build folder is mounted as nfs folder to
> embedded codec before starting apache.
>
> Am I missing any gotchas?
Yeah, don't use IE.
I'm serious. IE is fine for browsing web sites, but for testing your
configuration you'd be much better off with a tool that tells you
what's going wrong. For instance
curl -I http://yourbox:9090/ should give you a header back
curl -kI https://yourbox:9091/ should give you a header back, or a
connection error, or an openssl error, or...
So, the two million dollar questions:
1) What error does your client give you, and at which level?
2) What Does The Apache Error Log Say?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
[users@httpd] Apache in embedded product
Posted by "Malluru, Puri" <Pu...@polycom.com>.
Hi
I got Apache built for our embedded product (Linux running on Powerpc
platform). I configured it for http running on port 9090 and https
running on port 9091. I made htdocs a sym link to a folder with contents
that I created using "wget -m ..." command.
I found Apache serving https just fine. When I try to access the same
site with http, IE just waits forever.
Please note that this whole build folder is mounted as nfs folder to
embedded codec before starting apache.
Am I missing any gotchas?
Thanks for your help.
puri
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [PATCH 43415] Logging remote port.
Posted by Jeff Trawick <tr...@gmail.com>.
On 9/24/07, Jeff Trawick <tr...@gmail.com> wrote:
> On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
> >
> >
> > On 09/23/2007 10:49 PM, Jeff Trawick wrote:
> > > On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
> > >>
> > >>> -----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:
> > >
> > >> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
> > >> Maybe other have.
> > >
> > > %{canonical}p (default)
> > > %{local}p
> > > %{remote}p
> >
> > Sounds good to me.
>
> The attached patch works for me (though I haven't yet rebuilt the docs
> to see what that looks like).
I'm planning to commit sometime tomorrow unless somebody objects...
--
Born in Roswell... married an alien...
Re: [PATCH 43415] Logging remote port.
Posted by Jeff Trawick <tr...@gmail.com>.
On 9/24/07, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 09/23/2007 10:49 PM, Jeff Trawick wrote:
> > On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
> >>
> >>> -----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:
> >
> >> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
> >> Maybe other have.
> >
> > %{canonical}p (default)
> > %{local}p
> > %{remote}p
>
> Sounds good to me.
The attached patch works for me (though I haven't yet rebuilt the docs
to see what that looks like).
[trawick@linux httpd]$ egrep
'(^ServerName|^.VirtualHost|^Listen|ports$)'
/scratch/inst/23/conf/httpd.conf
Listen 8089
LogFormat "%h %l %u %t \"%r\" %>s %b PORTS: %p %{canonical}p
%{local}p %{remote}p %{bogusarg}p" ports
CustomLog logs/access_log ports
<VirtualHost *:8089>
ServerName localhost:9999
[trawick@linux httpd]$ tail -1 /scratch/inst/23/logs/access_log
127.0.0.1 - - [24/Sep/2007:07:56:55 -0400] "GET / HTTP/1.0" 200 45
PORTS: 9999 9999 8089 65001 bogusarg
--
Born in Roswell... married an alien...
Re: [PATCH 43415] Logging remote port.
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/23/2007 10:49 PM, Jeff Trawick wrote:
> On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
>>
>>> -----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:
>
>> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
>> Maybe other have.
>
> %{canonical}p (default)
> %{local}p
> %{remote}p
Sounds good to me.
Regards
Rüdiger
Re: [PATCH 43415] Logging remote port.
Posted by Jeff Trawick <tr...@gmail.com>.
On 9/18/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
>
>
> > -----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:
> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
> Maybe other have.
%{canonical}p (default)
%{local}p
%{remote}p
Re: [PATCH 43415] Logging remote port.
Posted by Brian Rectanus <br...@gmail.com>.
On 9/19/07, Plüm, Rüdiger, VF-Group <ru...@vodafone.com> wrote:
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Adam Hasselbalch Hansen
> > Gesendet: Mittwoch, 19. September 2007 11:13
> > An: dev@httpd.apache.org
> > Betreff: Re: [PATCH 43415] Logging remote port.
> >
> >
> > Plüm wrote:
> >
> > > 1. Please provide a patch against trunk.
> >
> > mod_config_logger.c hasn't changed in trunk, so the patch
> > will work fine.
>
> Sorry. Just a default comment if someone sends in a patch that is not
> against trunk :-).
>
> >
> > > 2. Please also add a patch for the documentation.
> >
> > Done.
>
> Fine, I have already seen it in the report.
>
> >
> > > 3. I am not too happy with using %R, but to be honest I
> > have no better proposal :-).
> > > Maybe other have.
> >
> > Well, then... ;)
>
> I will leave around for just one or two days. If nobody has a better
> idea we just take %R. Feel free to bug me if your patch falls off my radar.
There is an article on ONLamp a while back that used %S. But I like
%R better ;)
http://www.onlamp.com/pub/a/apache/2004/04/22/blackbox_logs.html?page=3
The patch just uses apr_itoa()
-B
Re: [PATCH 43415] Logging remote port.
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Adam Hasselbalch Hansen
> Gesendet: Mittwoch, 19. September 2007 11:13
> An: dev@httpd.apache.org
> Betreff: Re: [PATCH 43415] Logging remote port.
>
>
> Plüm wrote:
>
> > 1. Please provide a patch against trunk.
>
> mod_config_logger.c hasn't changed in trunk, so the patch
> will work fine.
Sorry. Just a default comment if someone sends in a patch that is not
against trunk :-).
>
> > 2. Please also add a patch for the documentation.
>
> Done.
Fine, I have already seen it in the report.
>
> > 3. I am not too happy with using %R, but to be honest I
> have no better proposal :-).
> > Maybe other have.
>
> Well, then... ;)
I will leave around for just one or two days. If nobody has a better
idea we just take %R. Feel free to bug me if your patch falls off my radar.
>
> > 4.
> >
> > Instead of using
> > + return apr_psprintf(r->pool, "%u",
> r->connection->remote_addr->port);
> > I would prefer
> > + return pfmt(r->pool, (int) (r->connection->remote_addr->port));
> > like used for log_status.
>
> Well, in log_server_port, apr_psprintf is used, so that's
> what I used.
> But I really don't care one way or the other. Is there a particular
> reason for using one or the other?
I think that using pfmt is more efficient and burns less cycles than apr_psprintf
(I think this would be also the case for log_server_port), but I may be wrong on this.
Additionally pfmt checks if port is <= 0 and logs a "-" in this case, but this should not
be the case for r->connection->remote_addr->port, so we could use format_integer or
apr_itoa directly.
Regards
Rüdiger
Re: [PATCH 43415] Logging remote port.
Posted by Adam Hasselbalch Hansen <ah...@one.com>.
Plüm wrote:
> 1. Please provide a patch against trunk.
mod_config_logger.c hasn't changed in trunk, so the patch will work fine.
> 2. Please also add a patch for the documentation.
Done.
> 3. I am not too happy with using %R, but to be honest I have no better proposal :-).
> Maybe other have.
Well, then... ;)
> 4.
>
> Instead of using
> + return apr_psprintf(r->pool, "%u", r->connection->remote_addr->port);
> I would prefer
> + return pfmt(r->pool, (int) (r->connection->remote_addr->port));
> like used for log_status.
Well, in log_server_port, apr_psprintf is used, so that's what I used.
But I really don't care one way or the other. Is there a particular
reason for using one or the other?
> 5. Thanks for your patch :-).
Welcome :)
/Adam
Re: [PATCH 43415] Logging remote port.
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----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