Re: Expired sessions and relative image links
Re: Expired sessions and relative image links
- Subject: Re: Expired sessions and relative image links
- From: Tim Worman <email@hidden>
- Date: Mon, 22 Aug 2011 13:24:06 -0700
This issue appears to be resolved. And, it appears it has no relationship to the other other issue I'm experiencing. DOGGONIT!! :-)
So, um, set your frameworksBaseURL.
Tim Worman
UCLA GSE&IS
On Aug 22, 2011, at 11:42 AM, Tim Worman wrote:
>
> On Aug 22, 2011, at 11:26 AM, Chuck Hill wrote:
>
>>
>> On 2011-08-21, at 12:33 PM, Tim Worman wrote:
>>
>>> On Aug 21, 2011, at 11:49 AM, Chuck Hill wrote:
>>>
>>>>
>>>> On 2011-08-20, at 11:28 AM, Tim Worman wrote:
>>>>
>>>>> It's taken me a few days to get back to this due to a deployment.
>>>>>
>>>>> On Aug 10, 2011, at 7:51 AM, Chuck Hill wrote:
>>>>>
>>>>>> On 2011-08-10, at 7:03 AM, Timothy Worman wrote:
>>>>>>> On Aug 9, 2011, at 9:46 AM, Chuck Hill wrote:
>>>>>>>
>>>>>>>> Hi Tim,
>>>>>>>>
>>>>>>>> I am not really clear on what you are doing and what the problem is. This code should only affect URLs that get sent into your application. Which should be none. Why do you have relative URLs to resources? Have you looked at the BASE tag, http://www.w3schools.com/tags/tag_base.asp? That maybe a better solution to your problem.
>>>>>>>
>>>>>>> I do believe I have relative urls in my css pointing to images used by the css. I can't look at the moment but I used suggestions I found on the list to do it. Maybe this causes issues.
>>>>>>
>>>>>> Wonder uses this (e.g. the Ajax frameworks) so it should work if you have a Wonder app. Check the page source, does the CSS link look like this:
>>>>>>
>>>>>> <link rel="stylesheet" type="text/css" href="/cgi-bin/WebObjects/AjaxExample.woa/_wr_/wodata=/Users/chuck/Documents/Wonder/Frameworks/Ajax/Ajax/build/Ajax.framework/WebServerResources/modalbox.css"/>
>>>>>
>>>>> No, in deployment that page resources are linked like:
>>>>>
>>>>> <link rel="stylesheet" type="text/css" href="/WebObjects/Frameworks/GSEISCoreFramework.framework/WebServerResources/core.css"/>
>>>>> <script src="/WebObjects/Frameworks/Ajax.framework/WebServerResources/prototype.js"></script>
>>>>> <link rel="stylesheet" type="text/css" href="/WebObjects/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.css"/>
>>>>
>>>> That is vended through Apache. Those won't reach the app (unless you have some whacky rewrite rules :-)
>>>
>>> The only rewrite rules I use are the ones to convert my /cgi-bin/WebObjects bla bla into the app name.
>>>
>>> But I'm pretty sure I do have a problem here. :-) Because what I'm actually doing is creating symlinks in /Library/WebServer/Documents/WebObjects/Frameworks to the actual embedded framework resources in the split install of the app. I have to because those are the paths where the app tries to discover those resources in deployment. But I'm not really sure when this started to be a problem or why - I've always used the typical project layout and build files. Maybe my build files are behind the times? 'Cause they never really get updated unless you create a new project.
>>
>> You need this in the build.properties file of the app:
>>
>> frameworksBaseURL=/WebObjects/Cadre.woa/Frameworks
>>
>> http://davidleber.net/?p=279
>
> Thanks Chuck.
>
> I did find something about that last night - and I completely remember reading discussions about it related to WO 543 but I did not make the connection to any issues I was having since I wasn't seeing any grand failures in my apps. I'm gonna make sure this is set properly and see if it has any relationship to the other issue I've been tracking with requests not completing.
>
> Tim Worman
> UCLA GSE&IS
>
>
>>>>>
>>>>> In development they are linked more like:
>>>>>
>>>>> <link rel="stylesheet" type="text/css" href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Users/worman/Source/corewo/GSEISCoreFramework/WebServerResources/core.css"/>
>>>>> <script src="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/modalbox.js"></script>
>>>>> <link rel="stylesheet" type="text/css" href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/modalbox.css"/>
>>>>> <script src="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.js"></script>
>>>>> <link rel="stylesheet" type="text/css" href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.css"/>
>>>>
>>>> The app serves these.
>>>>
>>>>
>>>>>
>>>>>>>>>>>> What's been causing this for me are requests for "Ajax/WebServerResources/ibox/images/bg.png" when using AMD.
>>>>>>>>
>>>>>>>> I don't see why that should be. Are you using a custom CSS file with the AMD? Is the relative URL in there? That will only work with Wonder, and only if the image path is relative to the location of the CSS file in your project.
>>>>>>>
>>>>>>> I am not using custom css for the AMD. I'm simply using the component in my app. I didn't know any of this trouble was happening until I started trying to handle session restoration for ajax requests. Then I noticed that method was being called all the time and it seemed related to image files. At that point I started searching the list to figure out why that would be happening. That's what bought me here to Klaus' thread on the same topic.
>>>>>>
>>>>>> It should not be getting called all the time (obviously). Do you have CSS and images that are vended directly from Apache and not through the application? That is the only thing that I can think of.
>>>>>
>>>>> I think the above links reflect that they are being vended through apache?
>>>>>
>>>>> I also think this entire issue I've encountered is related to another issue I'm having that I brought up in January regarding runaway httpd threads.
>>>>>
>>>>> http://lists.apple.com/archives/webobjects-dev/2011/Jan/msg00224.html
>>>>>
>>>>> I'm still having that issue but I'm gonna bring that thread back so that subject stays on track.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>> Chuck
>>>>
>>>>>
>>>>>
>>>>>> Chuck
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> On 2011-08-05, at 12:51 PM, Timothy Worman wrote:
>>>>>>>>
>>>>>>>>> On Aug 5, 2011, at 12:17 PM, Chuck Hill wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2011-08-05, at 11:45 AM, Tim Worman wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm seeing this now and it's been driving me exactly bat-sh!t crazy. In all the threads I've read on this topic the only thing I haven't found is WHY it happens. Why do any of the transactions on my pages believe that image files are sessions ids? Anybody……….? Bueller………?
>>>>>>>>>>
>>>>>>>>>> The transactions on your pages _don't_ believe that image files are sessions ids. From that page:
>>>>>>>>>> The request URI looks like this: /cgi-bin/WebObjects/woapp.woa/wo/images/headerart.jpg.
>>>>>>>>>>
>>>>>>>>>> The /wo/ indicates that it is a session based, component request so WO just hands it off to the WOComponentRequestHandler. The WOComponentRequestHandler needs a session to handle the request, so it creates one if one does not exist. After that point it hits the error of the URL being nonsense.
>>>>>>>>>>
>>>>>>>>>> Chuck
>>>>>>>>>
>>>>>>>>> Thanks for the explanation Chuck - very much appreciated. After implementing Klaus's code, I'm now returning 404's on most of the images in my app - so they don't show up at least in development. So, this will fubar deployment. I am using Wonder/apache to rewrite urls. Do I have to get the rewriting involved in referencing my images properly now?
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What's been causing this for me are requests for "Ajax/WebServerResources/ibox/images/bg.png" when using AMD.
>>>>>>>>>>>
>>>>>>>>>>> …and maybe others.
>>>>>>>>>>>
>>>>>>>>>>> Oh, and thanks to Klaus for sharing the code!
>>>>>>>>>>>
>>>>>>>>>>> Tim Worman
>>>>>>>>>>> UCLA GSE&IS
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 4, 2009, at 7:03 PM, Klaus Berkling wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sometime back in 2005 Kaj Hejer posted a question about having a relative link to an image, and clicking links on the wo app page resulted in their custom 'session expired' page.
>>>>>>>>>>>>
>>>>>>>>>>>> The solution was to catch the request for the image in dispatchRequest and return a 404.
>>>>>>>>>>>>
>>>>>>>>>>>> Well I recently came acros the same type of problem. I though I'd share the code:
>>>>>>>>>>>>
>>>>>>>>>>>> http://web.mac.com/kib/page1/files/relative_image.html
>>>>>>>>>>>>
>>>>>>>>>>>> If you have sessions that you can't account for, this may be why.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> kib
>>>>>>>>>>>>
>>>>>>>>>>>> "The trouble with normal is it always gets worse."
>>>>>>>>>>>> Bruce Cockburn
>>>>>>>>>>>>
>>>>>>>>>>>> Klaus Berkling
>>>>>>>>>>>> Systems Administrator
>>>>>>>>>>>> DynEd International, Inc.
>>>>>>>>>>>> www.dyned.com | www.eskimo.com/~kiberkli
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chuck Hill Senior Consultant / VP Development
>>>>>>>>
>>>>>>>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>>>>>>>> http://www.global-village.net/products/practical_webobjects
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chuck Hill Senior Consultant / VP Development
>>>>>>
>>>>>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>>>>>> http://www.global-village.net/products/practical_webobjects
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Chuck Hill Senior Consultant / VP Development
>>>>
>>>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>>>> http://www.global-village.net/products/practical_webobjects
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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
_______________________________________________
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