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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
