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 "
There is no such link on that page. > > > > OR > > 1- http://www.deanza.edu > > 2- Click on "student" Students. > > 3- Click on "Apply for admission" > > 4- Click on Square " Returing User Login" This goes to https://tnapps1.fhda.edu/prod/web/default.jsp [the same as you gave above] > > 5- Click on 'De Anza - Registration " https://tnapps1.fhda.edu/prod/web/pinSelect.jsp?CAMPUS=DAWEBP > > 6- Click on "Click Here to Login with Existing Pin " https://tnapps1.fhda.edu/prod/tapp?Navigate=createPinIndex.jsp&CAMPUS=DAWEBP&START_APP=true&JSP_TYPE=web&WAITPAGE=PleaseWait.htm&OnError=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
