That's the problem. It shouldn't be (and probably isn't) a problem with anything! But it is a problem with something. Give a shout if you have any problems, and try with browsers from two different blood- lines.
Joe On Jul 26, 4:06 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: > Hey Joe, > > Sounds interesting - im actually doing something *very* similar but > with different 3rd party apps... I too have very long file names > (guids) and they work perfectly fine... I really dont think its a > problem with filename length - certainly not from a lift perspective > anyways. > > Cheers, Tim > > On Jul 26, 1:43 pm, Joe Wass <j...@folktunefinder.com> wrote: > > > I won't post code because the render is making calls to external > > programs so it wouldn't really help. > > > What happens is: > > - data extracted and written to a text file on disc with the name of > > the guid (under images/) > > - external program involved to produce postscript file with the same > > name in same location > > - external program (image magick convert) to convert to png with the > > same name in same location > > - image tag returned from snippet with the image name > > > So the images never go near a database, it's all on the filesystem. I > > think the code-side of things is perhaps a red herring anyway. > > > I've put a de-guidifier (a table that autoincrements for each unique > > guid request) which gives filenames like "5.png" instead. Since I've > > done that I've had no problems. So perhaps it's to do with the length > > of the file name? And maybe a quirk with Gecko (as it works with > > Webkit). > > > Either way, I think it's an ignore-until-it-happens-again kind of > > problem. > > > (I'm aware they're not really guids but for my purposes they are!) > > > Thanks for your interest > > > Joe > > > On Jul 26, 11:10 am, Timothy Perrett <timo...@getintheloop.eu> wrote: > > > > Hey Joe, > > > > Can you post your code? Are the images on the filesystem or held in a > > > database etc? > > > > Cheers, Tim > > > > On Jul 25, 7:28 pm, Joe Wass <j...@folktunefinder.com> wrote: > > > > > I'm completely stumped. I'll give the background for the sake of > > > > completeness but I'm not sure if it will help or not. It's more of a > > > > Jetty problem but perhaps someone here can help. > > > > > Standard Jetty set-up running one Lift instance. Mac OS X. > > > > > I have a snippet which transforms the XML input, renders an image, > > > > saves it to disc under the webroot/images/ directory with a filename > > > > taken from the MD5 of the contents, such as > > > > "c5669d3eedcf7d305dcf9f88a61b3ee0.png" . The snippet then returns an > > > > <img /> with a reference to the generated image for inclusion in the > > > > output. > > > > > Most of the time most of the images work. But most of the time some of > > > > them don't, and some of the images are not rendered by the browser. > > > > Attempting to view a problem image in the browser (Camino and Firefox) > > > > doesn't work: the image is not displayed, suggesting that something is > > > > vaguely wrong. Viewing it in another browser (Safari and with > > > > QuickTime), the image works fine. When viewing the file directly with > > > > Camino (i.e. file://...), the image shows fine (the file itself is not > > > > corrupted). I can only assume that something goes wrong in the > > > > transport of the image. > > > > > The URIs that do fail, fail consistently, it's not intermittent. > > > > Restarting Jetty makes no difference, so I don't think it's that the > > > > file was created after the server started. Also, the render is a > > > > blocking call, so there's no chance that the file is still open / > > > > hasn't been saved before the HTML is sent and the browser requests the > > > > images. > > > > > The only thing I can imagine is that the MIME type is mangled, so I > > > > put the appropriate mapping in web.xml: > > > > > <mime-mapping> > > > > <extension>png</extension> > > > > <mime-type>image/png</mime-type> > > > > </mime-mapping> > > > > > But still no cigar. The MIME type looks to be OK and I've verified > > > > that the number of bytes is correct. > > > > > HTTP/1.1 200 OK > > > > Expires: Thu, 01 Jan 1970 00:00:00 GMT > > > > Set-Cookie: JSESSIONID=1dbeh8eq4mtu0;Path=/ > > > > Content-Type: image/png > > > > Content-Length: 25488 > > > > Last-Modified: Sat, 25 Jul 2009 15:38:19 GMT > > > > Server: Jetty(6.1.16) > > > > > For completeness, the headers from an image that does load fine: > > > > > HTTP/1.1 200 OK > > > > Expires: Thu, 01 Jan 1970 00:00:00 GMT > > > > Set-Cookie: JSESSIONID=15dt649lzovc4;Path=/ > > > > Content-Type: image/png > > > > Content-Length: 18657 > > > > Last-Modified: Sat, 25 Jul 2009 15:41:35 GMT > > > > Server: Jetty(6.1.16) > > > > > Very very puzzled about this. Any clues? > > > > > Cheers > > > > > Joe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
