HTTPS OS PERSISTENCE TROUBLESHOOTING mr.aicache: Saw your email about persistence woes mr.aicache: I think it is related to the fact that persistence pegged for HTTP traffic has no effect on HTTPS and Vice Versa mr.aicache: So when you get pegged via HTTP req mr.aicache: and then request HTTPS server, the cookie is not only disregarded, mr.aicache: a new one is set, pegging you to the HTTPS server mr.aicache: and then, when you request HTTP server, same applies and new cookie is issued. mr.aicache: We added a way to have a pattern to say "when I am requested, dont send persistence cookie" mr.aicache: This way, you can add a pattern matching the HTTPS req and configure it not to blow up the existing cookie. that was previously set via HTTP request/response. Customer: so is that how similar apps work in that I will be able to say use the jsessionid to do the tagging? mr.aicache: The way AI does is the 1st time you request non-cacheable request, it sees what origin server it came back from and then it pegs your session to only be filled from that server mr.aicache: going forward Customer: ok Customer: so you need to enhance ai to support tagging of https traffic as a first step? Customer: when you say the https request above, do you mean a specific url pattern? mr.aicache: In your case mr.aicache: when one goes to HTTP site, you get a 302 redirect to HTTPS, mr.aicache: where you post log name and param and if these are correct mr.aicache: you get sent back to HTTP, but you MUST land on the original server you first came to, right? Customer: yes, that is correct Customer: within the application there are a set of pages that are required to run under https, for now this includes the log in page, user profile page, settings, etc Customer: but yes your description is correct above, we need to be pinned to the same server whether we are coming in as http or https mr.aicache: I c Customer: we may at some point in the future run the whole application as https (the set ofpages that require a user to be logged in) mr.aicache: but can you get them to hit origin over plain HTTP? mr.aicache: that would solve your problem mr.aicache: What you can do to protect those pages mr.aicache: is to catch them in aicache and redirect to HTTPS mr.aicache: The deal is : HTTP origin server = ! HTTPS origin server. mr.aicache: In ai's eyes these are completely different Customer: right, i see mr.aicache: so, u can have mr.aicache: pattern /login.php simple 0 mr.aicache: match_http_oonly mr.aicache: rewrite .+ https://blah/blah mr.aicache: and so on mr.aicache: this way these URLs can not come in over HTTP and if they ever do mr.aicache: ai redirects them to HTTPS versions Customer: right, mr.aicache: to make sure you dont cause endless redirection loop mr.aicache: you say "match HTTP reqs only" mr.aicache: on your origins, to make sure stuff is kosher Customer: but that still leads to the same problem as once you complete the log in action successfully then you should land at an http page mr.aicache: you can only allow aicache to connect to it mr.aicache: OR for certain URLs, you might want to make sure you know the request mr.aicache: originally came over HTTPS (client--> aicache) mr.aicache: aiCache sticks in certain header to help with that Customer: you are saying these are options we could do now? mr.aicache: yep mr.aicache: as long as you can disable use_os_https, aicache will go to them over HTTP mr.aicache: and then you will have HTTP-HTTPS persistence mr.aicache: in other words mr.aicache: if you go to http://blah mr.aicache: and then to https://blah mr.aicache: and then back to http://blah mr.aicache: you will stay on the same origin server mr.aicache: as long as all of your origin servers are HTTP mr.aicache: if you use HTTP and HTTPS origin servers mr.aicache: then every hop will break your persistence |
|
aiCache Wiki > HTTPS Configuration >
Troubleshooting HTTPS OS Persistence |