tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: loading images through a Servlet
Date Fri, 02 Oct 2015 15:04:04 GMT
Hash: SHA256


On 10/2/15 10:38 AM, André Warnier (tomcat) wrote:
> Chris, you're kind of breaking down an open door here. Bill was
> already at the stage of congratulating himself and dreaming of his
> retirement plan, following his discovery of a brilliant and 
> innovative solution. Better to start from the beginning of the
> thread..

Yep, I read the whole thread.

I don't think this is a million-dollar idea. If it was, I would never
have gone to college, having written one of these for a client while I
was in high school. In my case, it was a CGI that counted hits to an
image whilst simultaneously serving that image. No security or
anything like that, but the "security" in Bill's case is just a proxy
for "do something first, then serve an image".

I'm suggesting that Bill can focus on his "do something first" task
and delegate the serving of bytes to a tool more appropriate for the
task: the DefaultServlet.

- -chris

> On 02.10.2015 16:30, Christopher Schultz wrote: Bill,
> On 10/2/15 5:04 AM, Bill Ross wrote:
>>>> Thanks Andre for the well-considered reply. To Thad - thanks,
>>>> I also asked on stackoverflow after here.
>>>> I believe I have solved the obfuscation problem independent
>>>> of the javascript issue. What I just got working is
>>>> logically:
>>>> img.src = "/images/" + /servlet/getnext(params)
>>>> Where I now have a Servlet at /images that serves the file,
>>>> thanks to a generous coder at stackoverflow. I'll post the
>>>> nicely designed code here if anyone wants.
> Why not just use the DefaultServlet... that's what it's job
> already is. Or, do you need an image from a database or whatever?
>>>> I am adding a table to map random hashes to file names. I'll 
>>>> insert there and have getnext() return the hash instead of
>>>> the file name. The new Servlet I just added will look up the
>>>> hash, check the age of the record and refuse it if older than
>>>> a second, and then serve up the mapped file from the
>>>> filesystem with current date and some flippant random file
>>>> name in the headers.
> You could do your security-checking, and then simply forward() to
> the resource, then let the DefaultServlet actually serve the bytes.
> That allows you to use range-requests, etags, if-modified-since,
> and all that other good stuff.
>>>> So as far as I can see, the only thing not obfuscated is the
>>>> image itself and my ego, which is harmless here.
> What do you need to obfuscate?
>>>>> I can think of even more hare-brained schemes where for
>>>>> instance some Ajax function of yours could open a websocket
>>>>> connection to the server, and receive a stream of image
>>>>> objects from the server over that single connection and
>>>>> "plug" them into the page as appropriate.  But any kind of
>>>>> thing like that would start to deviate seriously from
>>>>> standard practices, and need a serious effort of
>>>>> development and debugging before it could be considered as
>>>>> "production-level".
>>>> This is exactly what I was fishing for, and I thought maybe
>>>> it had been solved in some javascript library.
> Do you need the image to be in an Image object, or do you want to
> put it into an <img> on the screen? If the latter, just change the
> value of the 'src' of the <img> and the browser will re-load the
> image from the server.
> -chris
>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message