You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bill Ross <ro...@cgl.ucsf.edu> on 2015/10/01 23:52:59 UTC
loading images through a Servlet
Please let me know if there is a better place to ask Servlet/javascript
interface questions.
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 - ?).
One motivation is to reduce the round trips to the server for faster
response time.
Another motivation is to keep the filename from the user.
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 02.10.2015 17:04, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> 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".
>
It is a bit more than that, though : a user cannot, for example, save the html page
containing the images, and then reload it later, and still see get the images with the
same image links, because they will have "expired". Neither can one of these image links
simply be copied to a friend in an email, and still work for the friend.
He also gets a specific action triggered when someone attempts this.
It is not something infinitely scaleable (the server-side hashtable would get quite
large), but it is a relatively simple scheme, usable in quite a number of scenarios.
> 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.
>
I would agree with you, except that at some point Bill mentioned serving the image content
out of a database blob.
That's something the Default Servlet couldn't do.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWDpzkAAoJEBzwKT+lPKRYSfMP/iGY3efmf9a4KQFbVj48vCT5
ual5F5U/wTtwnzHPoOV7sRVX+kkc1vrzvE+crU8yqwjfxzfulgIY+CY4x8udyd1x
lZvw8skRmOXmLve1EF9298YS7/xS0mwvk6BtxjLxKvpyJ5y4/cqeAfFiDR8k8P8o
foXNud5D8BqeScRIt8C2wBm8AWeodwZXsd3nhoa98q9n3ZbO+fIWKYS4JNKQOTGa
QZ4LOa8iUK215N5vgNoQSUeJcNvkZg5KjYwM637HyF4ro4OnKmqTrws9JjffUFaF
wcZMCc0113okWUx9tcrW9XnbbnA1qBkVtRmlYV4EcI+Ct267wR3jl6sthlSW7YMX
UJKtz3y6umZZckQpjLOqhM7Lwp0hi8lCPt2POVZEP+dYrO5OAG5f0ZidmPUc+GaH
DU810av0rbEBE1Cbydm3wF8m3NAcnmRxmTdx/UIOS/O/PJnO4N6bN4DQ3tm/h6aA
qnRDNGC9b6B6fXGqjHPW9bvrXl6bFkk1NhG8YeWLD9qdIlLrImcOwGzzQrFwBpw0
KhZp4u7I4fG02tA3R56tweNM26lCy2EVtA59G6yoOVuiir47KFdPFb7S5cJMVA/w
3LBbMSwqV4GC6+ejAL7tUHacZOlv2EGGH+EiJTroLGHj4I7371qV2lPidHY4Bp+n
EGQeBtgkbd4/2IiDMCcv
=WBGN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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..
On 02.10.2015 16:30, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWDpT2AAoJEBzwKT+lPKRYdj0P/iTqUq5FTYeTgVjJtLXEMile
> 74ql5SalOtbERrTvyY72d4wHjlnWUYJCJeJOTWyDU3grJsG7OBxHpiWEQEI5c9GV
> xEhhGrlI1vOIdJ3gZRCgnrPDV8pdXTS4Sg8zEuLpW5ITRLEJsnHQz6yJDkbLofYz
> w9ACt/Dllv/kcJPHrIu9+J5xgLAEUPKIHuu1mM9TkTWeSYepuR8grm3A2GFO999D
> +5MIkd/XpkfTK88/yGP6Q2xtXgXAtnI5Ug0e5S72gkGFRsHYV5iWb9yBRoji7W09
> G1uOJPm3xiCED2bLsiFBZmhgv/YrmCoVx4EbLnsYO/92tkHT1+2zly2bmKZc/AoC
> LXoWI/trEiE2MUWvYlwftyEZvBLsJQCqrHfo6MOwPNwY2YFhv+GYl7E5N+QcQZf5
> eCu/vzCvsDZHz7QrVHwInDKXeD2iZ3JxMRVPFT7kIfD/aTzrlFEGqZ+hG/pYsjWh
> Gv1l2vmfQkPu7/wmhoCscdcqwk9SMCYOWvK7/5ehSyZl/j/4J/zkqnkbU10HlxO+
> wVjt+cVYtrCHf7UXWInF86N5ZHSu9KVsmWdoMUUOxIFbGRQbSIvCVBzFPv+WIoR/
> G/hURioQXqcICmslbbhw9QwINuRWz7gpcp+Ll7Jj+3furtxYQwv6IB/qJSWSi/Ih
> lvNUQAkYta9Y+ZUGYAfE
> =5ruo
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWDpT2AAoJEBzwKT+lPKRYdj0P/iTqUq5FTYeTgVjJtLXEMile
74ql5SalOtbERrTvyY72d4wHjlnWUYJCJeJOTWyDU3grJsG7OBxHpiWEQEI5c9GV
xEhhGrlI1vOIdJ3gZRCgnrPDV8pdXTS4Sg8zEuLpW5ITRLEJsnHQz6yJDkbLofYz
w9ACt/Dllv/kcJPHrIu9+J5xgLAEUPKIHuu1mM9TkTWeSYepuR8grm3A2GFO999D
+5MIkd/XpkfTK88/yGP6Q2xtXgXAtnI5Ug0e5S72gkGFRsHYV5iWb9yBRoji7W09
G1uOJPm3xiCED2bLsiFBZmhgv/YrmCoVx4EbLnsYO/92tkHT1+2zly2bmKZc/AoC
LXoWI/trEiE2MUWvYlwftyEZvBLsJQCqrHfo6MOwPNwY2YFhv+GYl7E5N+QcQZf5
eCu/vzCvsDZHz7QrVHwInDKXeD2iZ3JxMRVPFT7kIfD/aTzrlFEGqZ+hG/pYsjWh
Gv1l2vmfQkPu7/wmhoCscdcqwk9SMCYOWvK7/5ehSyZl/j/4J/zkqnkbU10HlxO+
wVjt+cVYtrCHf7UXWInF86N5ZHSu9KVsmWdoMUUOxIFbGRQbSIvCVBzFPv+WIoR/
G/hURioQXqcICmslbbhw9QwINuRWz7gpcp+Ll7Jj+3furtxYQwv6IB/qJSWSi/Ih
lvNUQAkYta9Y+ZUGYAfE
=5ruo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by Bill Ross <ro...@cgl.ucsf.edu>.
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.
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.
So as far as I can see, the only thing not obfuscated is the image
itself and my ego, which is harmless here.
> 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.
> 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..
Maybe I will be selling to them :-) Thinking of my slideshow app overall.
Bill
On 10/2/2015 1:16 AM, André Warnier (tomcat) wrote:
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: loading images through a Servlet
Posted by Thad Humphries <th...@gmail.com>.
The servlet that gets the image is the src for the image. The servlet
should return the correct MIME type for the image (image/jpeg, image/png,
etc). Update the src attribute and the image should update. That's how I do
it. However I'm not writing straight JavaScript. You should put your
question to Stackoverflow.
On Thu, Oct 1, 2015 at 5:52 PM, Bill Ross <ro...@cgl.ucsf.edu> wrote:
> Please let me know if there is a better place to ask Servlet/javascript
> interface questions.
>
> 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 - ?).
>
> One motivation is to reduce the round trips to the server for faster
> response time.
> Another motivation is to keep the filename from the user.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)