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.

> 
>>>>> 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.

> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to