-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
André Warnier wrote: > From a front-end Apache, I am issuing a request to Tomcat, with the only > purpose of getting back a small string (a user-id). > I would imagine that for Tomcat generating a whole response (headers + > body) is heavier than generating just a set of headers. A filter is not much lighter than a servlet, depending on what you have it actually do: there's no performance gain from using a filter instead of a servlet. Tomcat's connectors are (almost) all HTTP connectors, so you're going to get a set of headers and a (possibly empty) body anyway. I find that it's more architecturally pretty to use filters for pre- and post-processing or requests and servlets for "real" work. Note that the Struts2 developers disagree ;) > So can I, from the filter as before, generate a response consisting > *only* of headers, among which one "propietary" one that would contain > the string I want. > > I would basically need only a response with > > HTTP status line > MyHeader: johnsmith > > (and no body) You can do this with a servlet, too. Just don't ever call response.getWriter or response.getOutputStream. > At the limit, it could even be just the status line, with my return > string in the message part. Yeah, but this might be a bit confusing as an HTTP response. I'd stick with either a header (which makes it a bit easier to identify a null string) or a single line of the response body. If you don't need HTTP, why not use a separate protocol? Obviously, SOAP is way heavier, but you could create something super simple. Then again, integrating it with Tomcat's session management, etc. would be a giant headache. On second thought, you should stuck to Tomcat's built-in HTTP connectors. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklZNEkACgkQ9CaO5/Lv0PCnmQCfS1EEudjd9uqbuLdLAk9Eev13 JRsAn2ly4T4nf0VOdkmRj9kBn1ss8N7p =E8HQ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
