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.
But 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 : http://www.w3schools.com/jsref/dom_obj_image.asp
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.
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, refer to
basic principle above.
One motivation is to reduce the round trips to the server for faster
response time.
Basically, you still have to retrieve the image from the server, so I
do not believe that you will 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 e.g., 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).
(*) 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.
See basic principle. 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 ?
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
