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 : 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. (So in a way, you would be creating your own little internal HTTP forward proxy
server).
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 : https://en.wikipedia.org/wiki/HTTP/2
(*) 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
