On Mon, 2007-03-26 at 10:47 -0600, Joe Lewis wrote: > Ralf Mattes wrote: > > On Mon, 2007-03-26 at 10:14 -0600, Joe Lewis wrote: > > > >>> Sam Carleton wrote: > >>> > >>> > >>>> On 3/26/07, Issac Goldstand <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> If the images are already on the server, and needed for the response > >>>>> immediately, you'd need to do it inline, but you could still make life > >>>>> easier on yourself (somewhat) by caching the reduced images to avoid > >>>>> reprocessing. > >>>>> > >>>>> I could give more specific advice if you could share a bit more about > >>>>> what you're trying to accomplish in general. > >>>>> > >> Another alternative is to cause the image links to point to a directory, > >> and use > >> > >> ErrorDocument 404 /cgi-bin/script-to-generate-thumbnails.pl > >> > >> > > > > No -- please don't do that. You are terribly abusing the protocol. > > An "Error Document" is just this - an indication of what went wrong. > > The client will still receive a 404 status, and, expecting an _image_, > > just display the dreaded broken image icon ... > > > If the script responds with the generated image and the proper content > type, it would work. I never said it would be "pleasant". But my > question is : how does the use of an ErrorDocument generator to generate > content that doesn't exist into a static form become abuse of the > protocol? The ErrorDocument in Apache 2.2 really creates a sub request > to grab that, so I don't think it's really a bad idea. Isn't that why > the ErrorDocument directive was even implemented, so that the > administrators could customize the responses on certain error codes?
No -- the ErrorDocument was implemented so that Lusers would see 'pretty' error reports instead of those "boring" Apache-genereated pages - IIRC there were even "Cool 404 page" contests (really!). Of course, nowhere did the standard require a client to even look at the content part of a 404 resopnse ... ;-/ > > Yes, it may not be as "cool" as building a separate process to do what > needs to be done, but it is similar to generating the content and > caching it. It might break in subtle ways ... I've done it and i've been bitten. Since the OP seems to feel comfortable in C/C++ I'd write a custom handler module that generates the scaled image on the fly and saves it into a cache. Cheers, RalfD > (Oh, and feel free to use any extension that maps to a packaged > thumbnail generator - as long as the script to generate it works). Yes, > it may not be as "cool" as building a separate process to do what needs > to be done, but it is similar to generating the content and caching it. > (Sam - is this supposed to be "O.S. independent"? Are you shipping the > source code?) > > Joe > > > BTW, with HTTP/1.1 and chunked encoding there shouldn't be any problem > > generating the image on the fly and then storing it in the cache. > > And there _are_ response status that indicate a lengthy content > > generation ... > > > > HTH Ralf Mattes > > > > > >> Which CGI generates the image and dumps it to the browser as well as > >> storing it. Then, each subsequent image request comes from the static > >> file. If you need them to be cleaned up once in a while and > >> regenerated, just create a cron job with "find" to locate the "old" > >> thumbnails and delete them, which causes the 404 and regenerates the > >> images. > >> > >> Joe > >> > > > > > >
