Thanks folks... My goal is to deliver PDFs back to an automated process from an already existing Web application (it's internal so security isn't an issue), which has a Struts front end for the UI. A simple HTTP GET request seems to fit the bill.
Once the automated process has been written the validation will be largely superfluous as the request data should always(?) be right, so I think I can probably get away with a status code (404?) with no message, and just use logging to record the nature of problems. Thanks again for your help. Mark. newton.dave wrote: > > FWIW, I did a quick dispatcher result hack that allows setting the HTTP > result; we use it for Ajax calls (not 404s). I'll probably fold that > property back into S2, but like Wes said it's not so handy for 404s. > > Dave > > Wes Wannemacher wrote: >> 404 is a tricky header... Most of the time, you really don't want to >> send content along with an http header, think of redirects, etc. If >> you want some app-specific behavior, I would try to fit it into your >> app rather than trying to munge headers. In the case of redirects, >> when you see content it is because the redirect is happening with >> either meta-refresh or javascript. When the web server sends a 302 (or >> whatever the number), you don't see anything but a blank page (or the >> previously loaded page) in the browser. One nifty trick I have seen is >> to go to a "landing" page that has a meta-refresh who's target is >> redirected... Not sure how that is better, but my brain nearly >> exploded when I tried to figure out what was going on. >> >> What makes 404 tricky is that it is a header that is often associated >> with content, since no one likes to see the stock >> apache/tomcat/jetty/whatever error pages. The saving grace here is >> that you can use web.xml in a container-nonspecific way to create a >> 404 page. If what you're looking for is to pretty-up the 404 page, use >> web.xml and skip any of the struts configuration. If you are looking >> to incorporate 404 into some sort of application-specific logic, make >> sure that's *really* what you want to do first, then if so, check one >> more time before you do it, then after that, that is when you'll want >> to try to code up your solution. >> >> -Wes >> >> On Wed, Sep 2, 2009 at 9:33 AM, Mark Rollins<mark.roll...@computer.org> >> wrote: >>> Thanks Wes. >>> >>> The 'documentation' (it's very limited) gives the impression that you >>> can >>> specify an error message when using the errorMessage parameter with the >>> error parameter, and even being able to pick up a message from the value >>> stack using an OGNL expression. >>> >>> Having looked at what is returned (firebug in firefox), I can see no >>> mention >>> of the error and the content (as you said) is empty. >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/httpheader-result-type-tp25254438p25257727.html >>> Sent from the Struts - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>> For additional commands, e-mail: user-h...@struts.apache.org >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > -- View this message in context: http://www.nabble.com/httpheader-result-type-tp25254438p25273805.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
