On 8/25/2012 11:42 AM, Terence M. Bandoian wrote:
On 8/25/2012 7:01 AM, Konstantin Kolinko wrote:
2012/8/25 Mark Eggers <its_toas...@yahoo.com>:
On 8/24/2012 2:55 PM, Konstantin Kolinko wrote:
2012/8/25 Mark Eggers <its_toas...@yahoo.com>:
(...)
An application makes use of a PDF library which generates PDFs from
JSP
pages. One of these pages includes a dynamically generated graph.
This library cannot use streaming data to include the graph.
(...)
============
3. What is your hairpinning problem?
Hairpinning is when a system is sitting behind a NAT, and it attempts to
send itself a packet to the public IP address.
+----------------<
| NAT <----------------> Server
+---------------->
public IP private IP
ww.xx.yy.zz aa.bb.cc.dd
In this environment it occurs with a host name. The server sends a
packet to
itself using the publicly accessible name, which resolves to the
external IP
address (ww.xx.yy.zz), which then gets sent right back to the server.
Unless you specifically configure a NAT device to allow this, the packet
will be dropped.
Is it because you use "a fully qualified URL point to a servlet" and
you cannot build that URL correctly?
Do you really need an absolute URL? You mean that you cannot call your
servlet otherwise?
This is correct. The library in use will only take relative URLs, or
fully
qualified URLs (including protocol, port, and host name).
Relative URLs means I write back into the web application, which is
where
getRealPath() comes into play.
I cannot use absolute URLs (/context/servlet-name?imagename=foo).
This gets
interpreted by the library as an absolute file name (and no, using
/java.io.tmpdir/foo does not work).
I would love to rewrite my URL to be
http://localhost:80/context/servlet-name?imagename=foo
That will only work if there are no virtual hosts in any front end
proxy and
no additional hosts in server.xml.
I could write a separate application that serves the image files
internally.
It would be quite simple to do, but it would potentially require server
modifications.
1. Listens to requests on a separate port (server.xml modification)
2. Application resides in the default host (for multi-host configs)
Then the path would look something like the following.
A. Request
Browser ------------> NAT ------------> Server
public IP private IP
ww.xx.yy.zz aa.bb.cc.dd
B. Image
+-----< Server
| ^
| | localhost - some arbitrary port
+---------+
C. Resulting PDF
Browser <------------ NAT <------------ Server
public IP private IP
ww.xx.yy.zz aa.bb.cc.dd
That PDF-generating library - where it sits? Is it on Server?
How does the library get its source data (an XSL-FO document?) that is
converted to PDF? Which of the following:
a) It uses HTTP to request a JSP page. Then it uses HTTP to request
the image.
b) You prepare the data and feed it to the library programmatically
(e.g. as an InputStream). The library performs a request to get the
image.
If it is a) you could use UrlRewriteFilter + forward to serve the
image from any arbitrary URL.
If it is b),
- How the library knows the base URL of the document, to resolve
relative links?
- Could you use a "file:///" URL for the image?
- Does the library use some resolver before looking for the image
(e.g. javax.xml.stream.XMLResolver, org.xml.sax.EntityResolver),
so that you can intercept the lookup.
- In theory, it is possible to use custom URL schemes, like Tomcat's
internal jndi:// one.
Best regards,
Konstantin Kolinko
If you're embedding the image in the PDF, a file: URL might be the best
way to go. As a workaround, you might consider configuring the absolute
pathname of a work directory as a system property and using that to
store the image and create the file: URL.
-Terence Bandoian
I've tried an absolute file name, which doesn't seem to work with the
PDF library. This is quite odd, since part of their documentation on the
prohibition of using absolute URLs states:
Image should be referenced with relative path. Absolute URLs, like
src="http://myserver:80/path/to/img.gif"; are allowed as well, but
src="/path/to/img.gif" not.
I'll try a file URL, but without knowing the mechanism that is being
used to resolve the reference, it'll just be trial and error.
While I appreciate all of the help being given in this discussion, we've
wandered quite far afield from Tomcat stuff. I'm thinking of marking
future replies as [OT] just so that people won't get bogged down in the
minutia of a third party library issue.
Again, thanks lots.
I now have four games to play:
1. file URL - I suspect this will fail
2. UrlRewriteFilter - rewrite to localhost
a. This will work if everything is on one host and
b. I'm allowed to connect to it via HTTP
c. It's the only host or request headers contain the host name
3. UrlRewriteFilter - rewrite to IP address (see above for issues)
4. File(System.getProperty("catalina.base")).getCanonicalPath()
The last is a Tomcat-specific solution. This makes the web application a
bit less portable, but in this case that's not an issue.
In ease of testing, 1 and 4 seem to be simple to try. Items 2 and 3 will
require a bit of learning on my part (and adding another library to the
soup).
. . . just my two cents.
/mde/
Wow, again thanks for all the feedback. I have to say that this list is
probably one of the most productive / useful mailing lists I've ever
been on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
![http://myserver:80/path/to/img.gif"](http://myserver:80/path/to/img.gif"){kind=link}