On 6/2/06, Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> fre 2006-06-02 klockan 14:11 +1000 skrev Jarrod Harch:
>
> > - if client connects directly to the server without going through
> > Squid, the 302 is returned correctly.
> > - if DNS is altered to resolve to only one server, then a client
> > connecting through Squid doing such a POST results in 302, correct
> > behaviour.
> > - if using round-robin DNS and client POSTs via Squid, a 200 response
> > is sent back to the client and the original page displayed again
> > (incorrect behaviour). But refreshing the page reposts the data
> > correctly resulting in the 302.
>
> Very odd. Why would your web servers act differently depending on how
> the DNS is registered? My only guess is that the session data isn't
> replicated proper.
This was my first guess, but there's lots of other functionality that
relies on session data that works properly, and I've confirmed session
data is replicated before making the request. Only this particular
operation seems to have any issues.
The web servers shouldn't know or care about DNS or proxy/non-proxy.
It's a basic POST that should behave the same even if it's the first
thing a client ever sends to the server.
>
> When using Squid the requests gets distributed among both servers, even
> if from the same client.
Yep, I confirmed this from monitoring access.log. That's fine, it
shouldn't break anything provided session data is OK.
>
> Then using direct connection the client resolves the IP once and then
> generally sticks to that IP for the session (or at least until error).
Yes this appears standard for clients I've tried.
If anyone knows another web browser that doesn't have this behaviour,
let me know; it would be useful to test this situation with a client
that distributes requests like squid does.
>
> Regards
> Henrik
>
OK, well I guess I'll have to put it down to IIS and dot net weirdness.
I'm confident the session data is good between the servers. Also, I
tried ngrep to monitor Squid's outbound requests and could find very
little difference between a failed one (that the website fails to
redirect) and a good one (redirected after refreshing the POST). I
can't see why IIS would handle the requests differently, maybe it is
dependant on server affinity in some other way apart from just the
session data.
Thanks Henrik,
Received on Fri Jun 02 2006 - 04:19:56 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Jul 01 2006 - 12:00:01 MDT