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