Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpServletResponse.sendRedirect(String location) builds absolute URL including protocol and server-name #10000

Closed
christophs78 opened this issue Dec 3, 2019 · 5 comments

Comments

@christophs78
Copy link

christophs78 commented Dec 3, 2019

Describe the bug
Doing response.sendRedirect("/frw-demo/index.xhtml") creates the follwing response on OpenLiberty 19.0.0.6:
sendRedirect_OpenLiberty

Steps to Reproduce
response.sendRedirect("/frw-demo/index.xhtml")

Expected behavior
Apache Tomcat 9 does the following:
sendRedirect_Tomcat9

Diagnostic information:

  • OpenLiberty Version: 19.0.0.6
  • Java Version: OpenJDK 64-Bit Server VM, version 1.8.0_163-b01 (en_AT)

Additional context
This causes troubles behind some Reverse-Proxies.

Think the issue is related to https://github.com/OpenLiberty/open-liberty/blob/master/dev/com.ibm.ws.webcontainer/src/com/ibm/ws/webcontainer/webapp/WebAppDispatcherContext.java method convertRelativeURIToURL.

Let´s compare this to the Tomcat-implementation:
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/connector/Response.java method sendRedirect

I also did some Google-Research and https://stackoverflow.com/questions/8250259/is-a-302-redirect-to-relative-url-valid-or-invalid tells us relative redirects are allowed.

From my view the Tomcat-behaviour is the right one. Or maybe a system-property should be introduced to make this behaviour configurable.
There´s already code like
if (com.ibm.ws.webcontainer.util.WebContainerSystemProps.getSendRedirectCompatibilty())

@christophs78 christophs78 added the bug This bug is not present in a released version of Open Liberty label Dec 3, 2019
@wtlucy
Copy link
Contributor

wtlucy commented Dec 3, 2019

The servlet sendRedirect spec is pretty clear here: the servlet container must convert the relative URL to an absolute URL before sending the response to the client. So the behavior Liberty has here looks correct, but we can explore the utility of making this configurable.

@christophs78
Copy link
Author

christophs78 commented Dec 3, 2019

The servlet-spec was written at a point in time when absolute URLs were mandatory.

Maybe no one has updated it since:

RFC 2616 requires an absolute URI in the Location, but that standard has been replaced, since June 2014. The relevant specification is now RFC 7231.

Making this behaviour configurable would be a good move in my opinion.

@wtlucy
Copy link
Contributor

wtlucy commented Dec 10, 2019

@pmd1nh has opened a servlet spec issue to get clarification for this behavior.

@pnicolucci pnicolucci added this to To Do in Web Tier Team via automation Mar 6, 2020
@pmd1nh pmd1nh removed the bug This bug is not present in a released version of Open Liberty label Jun 4, 2020
@pnicolucci pnicolucci added the release bug This bug is present in a released version of Open Liberty label Jun 8, 2020
@pnicolucci
Copy link
Member

@pmd1nh can this one be closed now that the PR you worked is integrated?

@pmd1nh pmd1nh closed this as completed Dec 7, 2020
Web Tier Team automation moved this from General Issues to Completed Tasks Dec 7, 2020
@k8vance88 k8vance88 changed the title HttpServletResponse.sendRedirect(String location) builds absolute URL including protocoll and server-name HttpServletResponse.sendRedirect(String location) builds absolute URL including protocol and server-name Jan 19, 2021
@pmd1nh pmd1nh removed the release bug This bug is present in a released version of Open Liberty label Jan 19, 2021
@pmd1nh
Copy link
Member

pmd1nh commented Jan 20, 2021

blog issue #15605

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Web Tier Team
  
Completed Tasks
Development

No branches or pull requests

5 participants