jsp - 为什么iframe让服务器发出请求而不是客户端

Question

我有这样的结构 jsp/iframe/jsp/img src=servlet

在访问日志中它显示服务器的 ip 地址使 servlet 请求不是 客户？ Servlet 地址是客户端在粘性上的集群地址的上下文变量 到特定服务器的 session ，但 iframe 不存在，如果到达另一台服务器， session 数据也不存在。

Tomcat 6 和 IE8

谢谢

Server #1 log
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "POST /membership
/GenerateSignatureServlet HTTP/1.1" 200 34

192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership
/printpage.jsp?type=newmem&trh=false HTTP/1.1" 200 997

192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership/js/newmember.js
HTTP/1.1" 304 -
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership/js/prototype- 
1.6.0.2.js HTTP/1.1" 304 -
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership/theme
/FBMembership.css HTTP/1.1" 304 -
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership/dhtmlmodal
/windowfiles/dhtmlwindow.css HTTP/1.1" 304 -
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership/theme 
/signature.css HTTP/1.1" 304 -
192.**.***.*** - agt**** [01/Jun/2012:09:23:55 -0500] "GET /membership
/signaturepageprint.jsp?trh=false HTTP/1.1" 200 51441

Server #2 log
172.**.***.*** - agt**** [01/Jun/2012:09:23:56 -0500] "GET /membership  


/GenerateSignatureServlet;jsessionid=91FFBB3EAA73F3833BA507B7B9B6B317?
action=generateSigImg     HTTP/1.1" 200 39466


Back to server #1
192.***.***.*** - agt**** [01/Jun/2012:09:23:58 -0500] "POST /membership/MoveToFileNet?action=mainprocess&type=mainprocess HTTP/1.1" 200 9

Answer 1

如果您有一个基于服务器的组件，该组件使用 HTML 并从该标记生成 PDF，那么从服务器请求 PDF 可能会导致服务器转向并向其自身(或另一个集群中的成员)以获取 HTML。

如果您不喜欢看到显示集群“ self 调用”的日志消息，您有几个我能想到的选项:

1. 当 PDF 生成器调用以获取 HTML 时，提供与代理相关的 HTTP header ，以便处理 HTML 请求的服务器记录请求，它看起来像是来自其他地方(例如客户端).请注意，运维人员可能不喜欢此选项，因为请求确实来自集群内部，现在来自外部。

2. 修改您的日志(或连接器)设置，以便以不同的方式记录这些环回请求。如果您使用单独的连接器，您可以获得本地主机通信速度，并且如果您使用 HTTPS，则完全避免 HTTPS 性能下降。或者，您可以在其他地方记录这些环回请求，这样它们就不会“污染”您的日志。

3. 通过在不发出 HTTP 请求的情况下创建 HTML 标记，重新设计生成 PDF 的工作流程。如果您使用的是 JSP，这可能是一项艰巨的任务，因为您必须让 JSP 编译器/运行器在 HTTP 请求的上下文之外工作，这不是它的设计方式。

无论如何，以这种方式记录这些请求有什么问题？