Re: Internal Server Error

Chances you are watching wrong error log

On 2002.03.12 00:50 "Pelton, James" wrote:
> Some of my links are now generating "Internal Server Error" messages.
> However, these events aren't showing up in my error log. How can I
> track
> down what's going on?
>
> james pelton
>

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re:

----__JWM__J38e6.6269S.0634M
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Type: text/plain; charset=windows-1252

Ok, now we're getting somewhere... just ENOUGH to eliminate the path inb=
etween... I'd just like to ask APACHE for a unique signature of the mach=
ine sending the message to compare it against others. Nothing more, noth=
ing less.


See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Sean Conner
To: users@httpd.apache.org
Subject: Re: [users@httpd]
Date: Tue, 10 Nov 2009 19:35:39 -0500

It was thus said that the Great Stephen Love once stated:
> So what you are telling me is that there IS no REAL 2-way handshaking
> going on. Then we've lost ALL hope of security.

There is a 2-way handshake, but it's at the TCP layer, which is used to=

establish a reliable, stream-oriented sequence of data. As far as the
browser and server are concerned, they're talking directly to each other=
:

HTTP client <-----> HTTP server


but in reality, the HTTP protocol is wrapped in the TCP layer:

HTTP client HTTP server
^ ^
| |
v v
TCP <-------------------> TCP =


but in reality, the TCP protocol (which establishes reliability and a
stream oriented (or line oriented if you care to view it that way) over =
the
IP protocol (which itself doesn't guarentee reliability, and is packet
oriented, not stream-oriented):

HTTP client HTTP server
^ ^
| |
v v
TCP TCP =

^ ^
| |
v v
IP <-----------------------> IP

And thus completes a full TCP/IP connection. IP itself is embedded in a=

multitude of hardware layer protocols, like Ethernet, T1 (which has a fe=
w
framing protocols itself), PPP, PPPoE, SCSI [1] or even avian carriers
[2][3], so the lower layers of the stack (below the IP layer) that get
stripped and added as the packet makes it way across the Internet. An
example might look like:

HTTP client HTTP server
^ ^
| |
v v
TCP TCP
^ ^
| |
v v
IP +- IP --+ +- IP --+ IP
^ | | | | ^
| | | | | |
v v v v v v
Ethernet <--> Ethernet T1 <--> T1 Ethernet <--> Ethernet
client router router server
^
|
Any number of hops here

(also note that the T1 listed here is just an example; it most likely i=
s
PPPoE over ATM (which comprises DSL I think), so there may even be a few=

layers below the IP layer)

The MAC address of the client doesn't even survive the first hop. The
server ends up with the MAC address of the router as the "sender", even
though the IP packet comes from the client somewhere else on the Interne=
t.

It helps to think of it this way: IP allows individual computers to
communiate; TCP allows individual programs to communiate.

Once you get a connection, you have a few pieces of information about t=
he
other side:

it's an HTTP connection (a given)
over a TCP connection (a given)
the local side's TCP port # (usually 80 if HTTP)
the local side's IP address (typically a given)
the remote side's TCP port #
the remote site's IP address

If you want more unique inforamtion, then you need to look into stuff l=
ike
cookies and session management (which is beyond the scope of HTTP for th=
e
most part).

-spc (Hope this clears up some misconceptions)

[1] RFC-2143 [5]

[2] RFC-1149, updated by RFC-2549

[3] No, really! It's even been done. [4]

[4] http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

[5] RFCs are documents that document the various Internet standards.

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Projec=
t.
See 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

____________________________________________________________
Diet Help
Cheap Diet Help Tips. Click here.
http://thirdpartyoffers.juno.com/TGL2131/c?cp=3DReODJzUqRaF2 DtAK679qBAAA=
Jz1cSR5zxtI8-KAHzBSY23cQAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAA AAAAAAAYQAAA=
AAA=3D
----__JWM__J38e6.6269S.0634M
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Type: text/html; charset=windows-1252

Ok, now we're getting somewhere... just ENOUGH to eliminate the pa=
th inbetween... I'd just like to ask APACHE for a unique signature of th=
e machine sending the message to compare it against others. Nothing more=
, nothing less.


See us online at http://www.LOVEnCompany.com.=


---------- Original Message ----------
From: Sean Conner <=
spc@conman.org>
To: users@httpd.apache.org
Subject: Re: [users@=
httpd]
Date: Tue, 10 Nov 2009 19:35:39 -0500

It was thus said =
that the Great Stephen Love once stated:
> So what you are telling=
me is that there IS no REAL 2-way handshaking
> going on. Then we=
've lost ALL hope of security.

 There is a 2-way handshake, =
but it's at the TCP layer, which is used to
establish a reliable, str=
eam-oriented sequence of data.  As far as the
browser and server=
are concerned, they're talking directly to each other:

HTTP clie=
nt <-----> HTTP server


 but in reality, the HTTP p=
rotocol is wrapped in the TCP layer:

HTTP client HTTP server
&=
nbsp; ^    ^
  |    | >  v    v
 TCP <-------------------&=
gt;   TCP

 but in reality, the TCP protocol (whic=
h establishes reliability and a
stream oriented (or line oriented if =
you care to view it that way) over the
IP protocol (which itself does=
n't guarentee reliability, and is packet
oriented, not stream-oriente=
d):

HTTP client HTTP server
  ^    ^<=
BR>  |    |
  v    =
v
 TCP   TCP
  ^    ^
=
  |    |
  v    v R> IP <----------------------->  IP

And thus comp=
letes a full TCP/IP connection.  IP itself is embedded in a
mult=
itude of hardware layer protocols, like Ethernet, T1 (which has a few >framing protocols itself), PPP, PPPoE, SCSI [1] or even avian carriers<=
BR>[2][3], so the lower layers of the stack (below the IP layer) that ge=
t
stripped and added as the packet makes it way across the Internet. =
 An
example might look like:

HTTP client   &nbs=
p;           &nbs=
p;           &nbs=
p;           &nbs=
p;  HTTP server
 ^       =
;            =
;            =
;            =
;         ^
 | &nbs=
p;           &nbs=
p;           &nbs=
p;           &nbs=
p;           &nbs=
p;  |
 v        &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;       v
TCP    =
            =
            =
            =
          TCP
 =
;^            &nb=
sp;           &nb=
sp;           &nb=
sp;           &nb=
sp;   ^
 |       &n=
bsp;           &n=
bsp;           &n=
bsp;           &n=
bsp;        |
 v  &=
nbsp;           &=
nbsp;           &=
nbsp;           &=
nbsp;           &=
nbsp; v
IP          =
;     +- IP --+      &=
nbsp;+- IP --+          &nb=
sp;IP
 ^          &=
nbsp;    |       | &nb=
sp;     |       |=
           ^
=
 |           &nbs=
p;   |       |   =
    |       |  &n=
bsp;         |
 v &=
nbsp;           &=
nbsp; v       v    &nb=
sp;  v       v    =
;        v
Ethernet <-->=
; Ethernet  T1 <--> T1   Ethernet <--> Ethern=
et
 client          =
;   router        rout=
er            &nb=
sp;server
          =
;            =
;       ^
    =
            =
            =
 |
Any number of hops here

 (also note that the T1 l=
isted here is just an example; it most likely is
PPPoE over ATM (whic=
h comprises DSL I think), so there may even be a few
layers below the=
IP layer)

 The MAC address of the client doesn't even survi=
ve the first hop.  The
server ends up with the MAC address of th=
e router as the "sender", even
though the IP packet comes from the cl=
ient somewhere else on the Internet.

 It helps to think of i=
t this way:  IP allows individual computers to
communiate; TCP a=
llows individual programs to communiate.

 Once you get a con=
nection, you have a few pieces of information about the
other side: R>
it's an HTTP connection (a given)
over a TCP connection (a give=
n)
the local side's TCP port # (usually 80 if HTTP)
the local side=
's IP address (typically a given)
the remote side's TCP port #
the=
remote site's IP address

 If you want more unique inforamti=
on, then you need to look into stuff like
cookies and session managem=
ent (which is beyond the scope of HTTP for the
most part).

&nb=
sp;-spc (Hope this clears up some misconceptions)

[1] RFC-2143 [5=
]

[2] RFC-1149, updated by RFC-2549

[3] No, really!  =
It's even been done. [4]

[4] http://en.wikipedia.org/wiki/IP_over=
_Avian_Carriers

[5] RFCs are documents that document the various =
Internet standards.

---------------------------------------------=
------------------------
The official User-To-User support forum of t=
he Apache HTTP Server Project.
See <URL:http://httpd.apache.org/us=
erslist.html> for more info.
To unsubscribe, e-mail: users-unsubsc=
ribe@httpd.apache.org
  "   from the digest: user=
s-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail=
: users-help@httpd.apache.org





______________________=
______________________________________

F2DtAK679qBAAAJz1cSR5zxtI8-KAHzBSY23cQAAYAAAAAAAAAAAAAAAAAAA DNAAAAAAAAAA=
AAAAAAAAAYQAAAAAA=3D target=3D"_blank">Diet Help
Cheap Diet Help Tips=
.. Click here.

----__JWM__J38e6.6269S.0634M--

Re:

On Tue, Nov 10, 2009 at 10:29 PM, Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of the
> machine sending the message to compare it against others. Nothing more,
> nothing less.
>
>
> See us online at http://www.LOVEnCompany.com.
>

Well, see my most recent message, but just to summarize, apache can't
uniquely identify the end machine on it's own, all it has is what that
machine send to it, which is IP packet, which contains the TCP packet,
which contains the HTTP packet, none of which include (on their own) a
unique identifier for the end machine. The best you can do with just
these protocols is generate a unique id, send it to the client, and
ask them to send it back. You can do this using cookies, or by
encoding the id in the URL. But either way, you're relying on the end
user to cooperate (i.e., send back the same identifier). If you're
looking for something that they can't reasonably fake or alter without
your knowing, you'll need a crypto protocol like TLS (again, see my
last message).

-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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:

Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of the
> machine sending the message to compare it against others. Nothing
> more, nothing less.
>
>

nope...



--
Norman Registered Linux user #461062

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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:

Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path inbetween... I'd just like to ask APACHE for a unique signature of the machine sending the message to compare it against others. Nothing more, nothing less.
>
>
> See us online at http://www.LOVEnCompany.com.
>
Well, it looks like this list already gave you all the possible
human-level help. If that does not solve your problem, maybe you should
ask for some higher-level intervention.


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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:

André Warnier wrote:
> Stephen Love wrote:
>> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
>> inbetween... I'd just like to ask APACHE for a unique signature of
>> the machine sending the message to compare it against others. Nothing
>> more, nothing less.
>>
>>
>> See us online at http://www.LOVEnCompany.com.
>>
> Well, it looks like this list already gave you all the possible
> human-level help. If that does not solve your problem, maybe you
> should ask for some higher-level intervention.
>
>
>
Please check the OSI systems stack for further information which is
directly compatible with the TCP/IP system's stack - in fact it's kind
of an expanded version that all network engineers use!!

Basically in the underlying network components you have physical, media
access, and network layers (1-3); layers 4-7 usually deal with the
computers themselves which start from ports and go to the apps themselves.

Now layer 2, at least true for Ethernet means that the MAC address of
the system is only point to point between machine and switch port, after
that things change. Layer 3 is convoluted by the intervention of NAT or
proxy so the only thing you are likely to get is the WAN IP address of
the network.

Unique identifiers are impossible, even using Cisco's proprietary CDP
(cisco discovery protocol) which discoverers neighboring Cisco devices
cannot go beyond next hop device as uses layer 2 addressing as reference!!!

The only way I suppose in theory one could do what you are after is for
the user to download a little app that has a unique signature and
broadcasts the full system info according to that. So at least with the
client part of the program you could have say 1 x 10^50 unique
signatures generated by a shell script or program then link them to a
server somewhere...... I do believe this is called spyware though and is
highly illegal!!!

In all honesty I think the best way is going through webalizer, GeoIP,
awstats, or Ntop!!! And if going through reverse proxy with Squid like
me; unlike me you can form the logs of Squid in a different way and
hence forward those to Apache, then get Apache to read those 'different'
logs so that you have the correct data collection available to you........
As far as I know of this would be about the only way to go! At least you
get the WAN IP of the remote network and can collect and collate
geographic locational information and also ISP info too :-)

Without using divine power or alien intervention.......


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: Spam:*****, Re: [users@httpd]

On Wed, 2009-11-11 at 14:54 +0200, Kaya Saman wrote:
> André Warnier wrote:
> > Stephen Love wrote:
> >> Ok, now we're getting somewhere... just ENOUGH to eliminate the path=20
> >> inbetween... I'd just like to ask APACHE for a unique signature of=20
> >> the machine sending the message to compare it against others. Nothing=20
> >> more, nothing less.
> >>
> >>
> >> See us online at http://www.LOVEnCompany.com.
> >>
> > Well, it looks like this list already gave you all the possible=20
> > human-level help. If that does not solve your problem, maybe you=20
> > should ask for some higher-level intervention.
> >
> >
> >
> Please check the OSI systems stack for further information which is=20
> directly compatible with the TCP/IP system's stack - in fact it's kind=20
> of an expanded version that all network engineers use!!
>=20
> Basically in the underlying network components you have physical, media=20
> access, and network layers (1-3); layers 4-7 usually deal with the=20
> computers themselves which start from ports and go to the apps themselves=
..
>=20
> Now layer 2, at least true for Ethernet means that the MAC address of=20
> the system is only point to point between machine and switch port, after=20
> that things change. Layer 3 is convoluted by the intervention of NAT or=20
> proxy so the only thing you are likely to get is the WAN IP address of=20
> the network.
>=20
> Unique identifiers are impossible, even using Cisco's proprietary CDP=20
> (cisco discovery protocol) which discoverers neighboring Cisco devices=20
> cannot go beyond next hop device as uses layer 2 addressing as reference!=
!!
>=20
> The only way I suppose in theory one could do what you are after is for=20
> the user to download a little app that has a unique signature and=20
> broadcasts the full system info according to that. So at least with the=20
> client part of the program you could have say 1 x 10^50 unique=20
> signatures generated by a shell script or program then link them to a=20
> server somewhere...... I do believe this is called spyware though and is=20
> highly illegal!!!
>=20
> In all honesty I think the best way is going through webalizer, GeoIP,=20
> awstats, or Ntop!!! And if going through reverse proxy with Squid like=20
> me; unlike me you can form the logs of Squid in a different way and=20
> hence forward those to Apache, then get Apache to read those 'different'=20
> logs so that you have the correct data collection available to you.......=
..
> As far as I know of this would be about the only way to go! At least you=20
> get the WAN IP of the remote network and can collect and collate=20
> geographic locational information and also ISP info too :-)
>=20
> Without using divine power or alien intervention.......
>=20
>=20
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See 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
>=20
Isn't this being discussed in the wrong forum?

What is ***looks*** like is that you have a class of computers that you
need to query to find out which one sent the message/packet/transaction
or whatever. This is the classic case for a digital signature.

The group has to be reasonably finite since you need to have a public
key for each computer that you need to authenticate. Then send
something in each packet that has to be encrypted under the senders
private key. You can authenticate that it came from that sender by
decrypting under its public key. If the result is the original token,
then you can be reasonably certain where the message originated.

John




------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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:

On Nov 10, 2009, at 22:29 , Stephen Love wrote:

> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of
> the machine sending the message to compare it against others.
> Nothing more, nothing less.


Take a look at mod_usertrack: http://httpd.apache.org/docs/2.2/mod/mod_usertrack.html
If you don't trust cookies, then you're out of luck.

--
Rich Bowen
rbowen@rcbowen.com




------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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:

Rich Bowen wrote:
>
> On Nov 10, 2009, at 22:29 , Stephen Love wrote:
>
>> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
>> inbetween... I'd just like to ask APACHE for a unique signature of the
>> machine sending the message to compare it against others. Nothing
>> more, nothing less.
>
>
> Take a look at mod_usertrack:
> http://httpd.apache.org/docs/2.2/mod/mod_usertrack.html
> If you don't trust cookies, then you're out of luck.
>
(many) People on this forum have been trying to convince the OP in
(many) previous messages, some of them containing a wealth of
information and having required significant time to write, that the only
practical technical solution for what he seems to want to do, was using
cookies.
It is just that somehow he seems not to be of the believing kind.


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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