Thanks a lot, Mark, for analysing the default "sendRedirect()" method.
As you suggested, in my overridden method in the response wrapper I don't do 
any of these checks.
So everything works fine now, problem solved!

@Thomas - concerning SEO apparently it seems to be best practice to use 301 
redirects to fully keep  the page ranking of the page the request is redirected 
to.


-----Ursprüngliche Nachricht-----
Von: Mark Thomas <ma...@apache.org> 
Gesendet: Samstag, 5. Februar 2022 11:01
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Redirect with 301 for directory requested without trailing 
slash

On 04/02/2022 20:55, Christopher Schultz wrote:
> Benny,
> 
> On 2/4/22 11:06, Benny Kannengießer wrote:
>> Thanks again Mark for the tip!
>>
>> Like you suggested I wrapped the response, overriding "setStatus()" - 
>> but the method didn't get called because the wrapper is not a 
>> subclass of the original  response, it's just a façade. I think the 
>> "setStatus()" method of the wrapped response (inner object) was 
>> called (by "sendRerect())".

Correct. Sorry for the incorrect suggestion.

>> I'm not sure if it would be better if I used a dynamic proxy, not too 
>> much experience with that...
>>
>> I also tried overriding "sendRedirect()" on the wrapper, just setting 
>> the status to 301 and the location header to the location - and it 
>> worked! But I'm not sure,, somehow it feels wrong- especially 
>> compared with the implementation of "sendRedirect()" in 
>> org.apache.catalina.connector.Response which contains quiet some 
>> logic which I would circumvent.
>>
>> What would be your opinion?
> 
> Ugly and working beats pretty and useless any day IMHO.

+1.

The logic in o.a.catalina.connector.Response.sendRedirect() has to handle all 
possible use cases. You should be safe skipping most (all?) of it. Lets check 
them in turn:

- isCommitted()
   In your case, the response should never be committed so it is safe
   to skip this check.

- included
   Providing your app never includes a directory (which would be a
   very strange thing to do it is safe to skip this check.

- resetBuffer()
   The default servlet won#t have written anything so it is safe
   to skip this

- relative vs absolute redirect
   The default servlet generates an absolute redirect so it is
   safe to skip this

- redirect body
   This is disabled by default and you don't need it in this case
   so it is safe to skip this

- setSuspended(true)
   This protects against additional writes after the redirect. As
   long as nothing else writes to the response after your filter
   this is safe to skip

You are dependent on how the default Servlet is coded but I think there is a 
fairly low risk of problems there.

Mark



> 
> -chris
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Mark Thomas <ma...@apache.org>
>> Gesendet: Donnerstag, 3. Februar 2022 17:41
>> An: users@tomcat.apache.org
>> Betreff: Re: AW: Redirect with 301 for directory requested without 
>> trailing slash
>>
>> I didn't see a commit in the code but I didn't look into what
>> sendRedirect() does and I don't recall if there is a commit in there 
>> somewhere.
>>
>> The other option would be the wrap the response in the Filter and 
>> override setStatus() with something like:
>>
>> @Override
>> public void setStatus(int status) {
>>       if (status == 302) {
>>           super.setStaus(301);
>>       } else {
>>           super.setStaus(status);
>>       }
>> }
>>
>> Completely untested - might not even compile - but you get the idea.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to