Re: Odd backtracking error
Re: Odd backtracking error
- Subject: Re: Odd backtracking error
- From: Mark Wardle <email@hidden>
- Date: Thu, 26 Nov 2015 22:29:15 +0000
| Thanks Chuck. I’m not sure. How can I check that? I haven’t got a favicon set presently. It shouldn’t default to accessing it via WO should it? I had thought it independent and a function of apache but of course, I do have a rewrite rule which redirects / to my WOA so it might well be doing that! Not entirely sure how to check or indeed fix!
Mark
Is your web server (or Wonder) protecting /favicon.ico from getting to your app or handling it? That request won’t contain the cookies (IIRC) which results in a new session getting created and the app will return the cookie from the new session (usually
with an error response as it is not handling the request.
Chuck
Paul,
That sounds like what might be happening and explain the inconsistency depending on, perhaps, the URL entered.
I’ll give it a go. Thank you!
Mark
On 26 Nov 2015, at 22:16, Paul Hoadley < email@hidden> wrote:
Hi Mark,
On 27 Nov 2015, at 6:50 am, Mark Wardle < email@hidden> wrote:
I’m getting a weird backtracking error. I have a component which mainly uses component actions and one of these component actions uses target=“_new” to show a PDF document in a new window.
The action uses
WOResponse
response = WOApplication.application().createResponseInContext(context);
to create a new response.
Sessions are stored in cookies.
On some computers (but not all), when one clicks the link, I get a login page and in the log a session restoration error with no session. It works fine on other computers running the same version of IE. I can’t reproduce the problem at all on
my development machine.
Any ideas?
I’m not sure this would explain everything you’re seeing here, but you can get session loss (and the resulting unexpected bounce to a login page) when using cookies for session ID storage if WOSession.domainForIDCookies() is returning something
“too specific” for your deployment setup. By default, that method returns the application’s full path, right down to the “.woa” extension. So, for example, if you’re using URL re-writing in deployment, there could easily be a mismatch. I usually override it
to return “/”. Again, not sure it explains everything you’re seeing there, but it’s something to rule out.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden