tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: loading images through a Servlet
Date Fri, 02 Oct 2015 08:32:20 GMT
On 01.10.2015 23:52, Bill Ross wrote:
> Please let me know if there is a better place to ask Servlet/javascript interface questions.

For the javascript part, there are probably better places.  But the people here are 
awesome, so it's worth giving it a try.
For the servlet side of it, this /is/ probably one of the best places.

Since you are asking nicely, let's start with javascript :

First a general principle : if you are thinking about security or any form of obfuscation

in the face of a determined and competent client, basically forget it. To get an image or

anything else from a server, the browser (or else), has to know how to get it, so you need

to send it that information. And once the server sends any information to the client, it 
is no longer under your control, because the browser (or other program, such as curl and 
the like) is under total control of the client (user).

So, as long as /that/ is not your ultimate purpose,

> I have a slide show web page that does the logical equivalent of:
>      var img = new Image();
>      img.src = "/images/" + /servlet/getnextfile(params)
>      img.[onload]: document["image"].src = img.src; resizeImage();
> Rather than using the 'getnextfile' servlet to get a file name and then load it, I would
> like to have getnextfile return a stream of bytes from the database which seems feasible
> (streaming a BLOB I assume), but I don't know how to receive that into an Image (which
> wouldn't have 'src' set - ?).

Have a look here :

The javascript DOM "img" object does not seem to have any callable method by which it can

retrieve its own image content.  The only way to have it retrieve that content, is by 
changing its "src" property.  This you can do, and it will apparently refresh its own 
image by itself when you do.
But the "src" property has to be set to a URL, so it "retrieves itself" by making a HTTP 
call to the server.. chicken and egg kind of thing.

In a form of obfuscation, you could try to set the "src" property to something like 
'javascript: retrieve_image("some id")' (Note: I haven't tried this), and then have this 
"retrieve_image()" function be something in one of your javascript libraries, which would

in turn retrieve the image from the server, in a way less visible to the casual script 
kiddie.  (So in a way, you would be creating your own little internal HTTP forward proxy 

But do not forget that the browser first has to receive that javascript library from the 
server, so it has it, and the person controlling the browser can see it, and turn it off 
at will or modify it to do anything he wants; see basic principle above.

In a more sophisticated way, you can probably add a custom method to the img objects on 
the page (see jquery for that kind of thing), so that you can have them change their own 
src property and retrieve their content in a less-immediately visible way.  But again, 
basic principle above.

> One motivation is to reduce the round trips to the server for faster response time.

You still have to retrieve each image from the server, which in HTTP 1.1, means one 
request/response per image.  So I do not believe that you can gain much on that side.

Also, over quite a long period by now, as well browsers as webservers have been both 
well-debugged and optimised to death, to respectively retrieve and serve "things" using 
the "normal" HTTP methods (think of caching on both sides, and content compression), and 
avoid introducing security holes in the process (*).
Anything that you would do yourself is likely in the end to be even less optimised and secure.
(This is not to discourage innovation of course.  You might after all still invent a 
better mousetrap).

Maybe also read this :

(*) yes, I know, successive IE versions are kind of a counter-example to that statement.

> Another motivation is to keep the filename from the user.

Basic principle again.  Anyone who installs the "Web Developer" plugin into his Mozilla 
browser, can ultimately find out anything about anything that is part of the page shown in

the browser.

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".
So the question would be : is it worth it ?
(but then again, HTTP 2 ?)

P.S. and if you really want to know how to display tons of images fast, I suggest that you

have a look (in a manner of speaking of course) at some of those many XXX websites.  They

/must/ have ways to do this efficiently.. ;-)

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

View raw message