HTTP: can GET and POST requests from a same machine come from different IPs?

Question

I'm pretty sure I remember reading --but cannot find back the links anymore-- about this: on some ISP (including at least one big ISP in the U.S.) it is possible to have a user's GET and POST request appearing to come from different IPs.

(note that this is totally programming related, and I'll give an example below)

I'm not talking about having your IP adress dynamically change between two requests.

I'm talking about this:

IP 1:  123.45.67.89
IP 2:  101.22.33.44

The same user makes a GET, then a POST, then a GET again, then a POST again and the servers see this:

- GET  from IP 1
- POST from IP 2
- GET  from IP 1
- POST from IP 2

So altough it's the same user, the webserver sees different IPs for the GET and the POSTs.

Surely seen that HTTP is a stateless protocol this is perfectly legit right?

I'd like to find back the explanation as to how/why certain ISP have their networks configured such that this may happen.

I'm asking because someone asked me to implement the following IP filter and I'm pretty sure it is fundamentally broken code (breaking havoc for at least one major american ISP users).

Here's a Java servlet filter that is supposed to protect against some attacks. The reasoning is that:

"For any session filter checks that IP address in the request is the same that was used when session was created. So in this case session ID could not be stolen for forming fake sessions."

http://www.servletsuite.com/servlets/protectsessionsflt.htm

However I'm pretty sure this is inherently broken because there are ISPs where you may see GET and POST coming from different IPs.

Any info on this subject is very welcome.

Answer 1

Some ISPs (or university networks) operate transparent proxies which relay the request from the outgoing node that is under the least network load.

It would also be possible to configure this on a local machine to use the NIC with the lowest load which could, again, result in this situation.

You are correct that this is a valid state for HTTP and, although it should occur relatively infrequently, this is why validation of a user based on IP is not an appropriate determinate of identity.

Answer 2

For a web server to be seeing this implies that the end user is behind some kind of proxy/gateway. As you say it's perfectly valid given that HTTP is stateless, but I imagine would be unusual. As far as I am aware most ISPs assign home users a real, non-translated IP (albeit usually dynamic).

Of course for corporate/institutional networks they could be doing anything. load balancing could mean that requests come from different IPs, and maybe sometimes request types get farmed out to different gateways (altho I'd be interested to know why, given that N_GET >> N_POST).