Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=Fur2w0Wmb+JQcYlBgU7wrtp/1wWA/DhP7aoucjzY/ssZnDtxxWMoLJoYwY8ADJU6gcKyeFVf4oaxICGTk6ZNME4OZ1117WycjPw/bktTMzuGmmTYQgwasdqr+G8XCtlIAzxeo9m005Z2HFUZlbKfKgLhAH+aL+b19YArcnhmO2w=
  ;
Message-ID: <4A9E7A10.5040807@yahoo.com>
Date: Wed, 02 Sep 2009 09:58:40 -0400
From: Dave Newton <newton.dave@yahoo.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: httpheader result type
References: <25254438.post@talk.nabble.com>
	 <e34c19110909020611qd82020o8fa4d04483638ade@mail.gmail.com>
	 <25257727.post@talk.nabble.com>
 <e34c19110909020649s1047d8e7s11dce62251b6669f@mail.gmail.com>
In-Reply-To: <e34c19110909020649s1047d8e7s11dce62251b6669f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.rollins@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org