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 :-) > 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 _______________________________________________ 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
