|
Home > Archive > Squid > January 2005 > Re: [squid-users] Looks like cookie set up browser issue but it is
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [squid-users] Looks like cookie set up browser issue but it is
|
|
| Henrik Nordstrom 2004-04-29, 6:54 pm |
| On Thu, 22 Apr 2004, Zand, Nooshin wrote:
> Your web browser is not configured to accept "cookies".
> (or it does not support cookies)
> Please enable cookies in your web browser and try again.
>
> Any idea where is the issue?
Have you set the http_header_access directive? This directive is used for
HTTP anonymization and may cause such symptoms.
Regards
Henrik
| |
| Henrik Nordstrom 2004-04-29, 6:54 pm |
| Can it be reproduced without a valid pin?
Regards
Henrik
On Fri, 23 Apr 2004, Zand, Nooshin wrote:
>
> The web site is
> https://tnapps1.fhda.edu/prod/web/default.jsp then Click on
> "Click Here to Login with Existing Pin "
>
> OR
> 1- http://www.deanza.edu
> 2- Click on "student"
> 3- Click on "Apply for admission"
> 4- Click on Square " Returing User Login"
> 5- Click on 'De Anza - Registration "
> 6- Click on "Click Here to Login with Existing Pin "
>
> Many thanks,
> nooshin
> -----Original Message-----
> From: Elsen Marc [mailto:elsen@imec.be]
> Sent: Thursday, April 22, 2004 10:30 PM
> To: Zand, Nooshin; squid-users@squid-cache.org
> Subject: RE: [squid-users] Looks like cookie set up browser issue but it
> is not
>
>
>
>
>
>
> Do you have URL examples (websites) ?
>
> M.
>
| |
| Henrik Nordstrom 2004-04-29, 6:54 pm |
| On Fri, 23 Apr 2004, Zand, Nooshin wrote:
[vbcol=seagreen]
There is no such link on that page.
[vbcol=seagreen]
Students.
[vbcol=seagreen]
This goes to
https://tnapps1.fhda.edu/prod/web/default.jsp
[the same as you gave above]
[vbcol=seagreen]
https://tnapps1.fhda.edu/prod/web/p...p?CAMPUS=DAWEBP
[vbcol=seagreen]
https://tnapps1.fhda.edu/prod/tapp?...Error=error.jsp
This is very odd. The application is a https:// application, and there
basically is nothing Squid can do to affect the operation of this except
deny access to the server entirely. There certainly is nothing in squid
which can have any impact on the use of cookies on https:// sites.
But still, there seems to be a pattern here.. with Squid it fails every
time. Without Squid is works most of the time, but did fail for me a
couple of times even without using the proxy.
There defenitely is something fishy about this server. Don't know what
yet.
Looking at packet dumps.. nothing very obvious, but this server seems to
do some strange things at the end of the connection and so does squid. No
sign of data loss however. I do not have a 2.5.STABLE2 available to test
with, but there has been no changes in how Squid handles this during the
2.5.STABLE cycle. Also due to https:// it is not entirely trivial to look
into all details of the traffic at the packet level as it is encrypted.
The only remotely relevant change I can see is the fix for Bug #430 which
was fixed some time before 2.5.STABLE2 (this is included in 2.5.STABLE2).
Between 2.5.STABLE2 and 2.5.STABLE5 there has been no changes in how Squid
forwards https:// requests.
I will continue looking into this for some time as it interests me why
this site dislikes being proxied when there should not be any difference.
If it was a http site I could understand, but not in case of https.
Regards
Henrik
| |
| Henrik Nordstrom 2004-04-29, 6:54 pm |
| On Sat, 24 Apr 2004, Henrik Nordstrom wrote:
> I will continue looking into this for some time as it interests me why
> this site dislikes being proxied when there should not be any difference.
> If it was a http site I could understand, but not in case of https.
So far the conclusions is that this server is quite broken and I am
suprised it at all works.
* Most times (but not always) works when accessed directly using Mozilla
* Always fails when accessed via Squid
* Always fails when accessed by lynx
* Always fails when accessed by Konqueror
* Fails immediately when accessed using openssl s_client
* Fails differently when using s_client but waiting 1 second after
sending the request line before sending request headers..
I have not yet fully concluded why it most times works when using Mozilla
directly but never when accessed via Squid. From what I can see it should
fail when accessed directly as well, but appears not. I can only assume
there is some subtle timing difference or similar as the s_client test
indicates the server is very sensitive to timing that in terms of HTTP
should not have any meaning at all.
The odd thing is however that little or none of these timing differences
is present when going via Squid vs going direct.. still a mystery what
this server is doing or reacting upon. But one thing is certain, this
server is extremely fragile and is not working the way it is supposed to.
Regards
Henrik
| |
| aks_cis 2005-01-12, 11:35 pm |
| Dear Henrik,
Have you worked more on the problem or is it still persistemt. To refresh Your memory this is regarding cookie forwarding problem in Squid. I have observed it in Squid 2.5 STABLE 5. Another such website is
https://cccweb.cccs.edu/pages/web/d....jsp?CAMPUS=MCC
Regards
Abhishek
quote:
Originally posted by Henrik Nordstrom
On Sat, 24 Apr 2004, Henrik Nordstrom wrote:
> I will continue looking into this for some time as it interests me why
> this site dislikes being proxied when there should not be any difference.
> If it was a http site I could understand, but not in case of https.
So far the conclusions is that this server is quite broken and I am
suprised it at all works.
* Most times (but not always) works when accessed directly using Mozilla
* Always fails when accessed via Squid
* Always fails when accessed by lynx
* Always fails when accessed by Konqueror
* Fails immediately when accessed using openssl s_client
* Fails differently when using s_client but waiting 1 second after
sending the request line before sending request headers..
I have not yet fully concluded why it most times works when using Mozilla
directly but never when accessed via Squid. From what I can see it should
fail when accessed directly as well, but appears not. I can only assume
there is some subtle timing difference or similar as the s_client test
indicates the server is very sensitive to timing that in terms of HTTP
should not have any meaning at all.
The odd thing is however that little or none of these timing differences
is present when going via Squid vs going direct.. still a mystery what
this server is doing or reacting upon. But one thing is certain, this
server is extremely fragile and is not working the way it is supposed to.
Regards
Henrik
|
|
|
|
|