Project

General

Profile

Bug #2108

CGI local redirect not implemented correctly

Added by oblomov over 7 years ago. Updated 5 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
mod_cgi
Target version:
Start date:
2009-11-26
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:
No

Description

According to the CGI 1.1 specification http://www.ietf.org/rfc/rfc3875 section 6.2.2 Local Redirect Response, a CGI script can issue a Location: response containing an (absolute) path to a local resource, and in this case the server MUST generate the response that it would have produced in response to a request containing the URL scheme server-name ":" server-port local-pathquery"

This is currently non implemented correctly in lighttpd 1.4.24. If a CGI script issues a local redirect, this is handled by lighttpd as if it was a client redirect (6.2.3 in the CGI/1.1 spec): a 302 is returned to the client, pointing to the new location. Expected behavior would be for the server to do the redirect internally in this case instead.


Related issues

Related to Bug #2793: 1.4.40 regression: broken redirect (using Location) between url.rewrite-once URLsFixed2017-02-20

Associated revisions

Revision 8861c2bb (diff)
Added by gstrauss 12 months ago

[mod_cgi] handle local redirect response (fixes #2108)

RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875

x-ref:
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108

Revision f57d8c54 (diff)
Added by gstrauss 6 months ago

[mod_cgi] skip local-redir handling if to self (fixes #2779, #2108)

Loosen local redirect handling in mod_cgi to skip handling as local
redirect if the Location matches con->uri.path, since if the request
is intended to redirect back to the same CGI using the same request
method, path info, and query string, the CGI would logically just
return the final intended response. Loosening this handling avoids a
problem with applications (potentially) accessible through multiple
gateways, where the application is not aware of this specific handling
of Location in the Common Gateway Interface (CGI/1.1), the application
sends abs-path in the Location response header instead of absoluteURI,
and the application expects the client to receive this Location response
header instead of the server to process as a CGI local redirect.

One example of such an application is LuCI,
which sends Set-Cookie with Location: /abs-path
https://github.com/openwrt/luci

(Note that this loose check for matching con->uri.path is not perfect
and might not match if the CGI returned a path with a different case
and the server is on a case-insensitive filesystem, or if the path
returned by the CGI is rewritten elsewhere to a different con->uri.path
before getting to mod_cgi.)

RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875

x-ref:
"CGI local-redir handling conflicts with LuCI redirect w/ Set-Cookie"
https://redmine.lighttpd.net/issues/2779
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108

Revision dde50f19 (diff)
Added by gstrauss 5 months ago

[mod_cgi] RFC3875 CGI local-redir strict adherence (#2108)

RFC3875 CGI local-redir stricter adherence

do not apply local-redir if any response headers besides "Location"
do not apply local-redir if any response body has been received
(though it might not have been received yet, and we do not wait to find
out, if lighttpd is configured to stream response body back to client)

x-ref:
RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108

Revision 57ab20ac (diff)
Added by gstrauss 4 months ago

[mod_cgi] cgi.local-redir = [enable|disable] (#2108, #2793)

new directive cgi.local-redir = [enable|disable]

*disable* RFC3875 6.2.2 local-redir by default.
(behavior change from when local-redir support added in lighttpd 1.4.40)

The reason for this behavior change is that CGI local-redir support
(RFC3875 6.2.2) is an optimization. Absence of support may result in
additional latency in servicing a request due the additional round-trip
to the client, but that was the prior behavior (before lighttpd 1.4.40)
and is the behavior of web servers which do not support CGI local-redir.

However, enabling CGI local-redir by default may result in broken links
in the case where a user config (unaware of CGI local-redir behavior)
returns HTML pages containing *relative* paths (not root-relative paths)
which are relative to the location of the local-redir target document,
and the local-redir target document is located at a different URL-path
from the original CGI request.

x-ref:
RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
http://www.ietf.org/rfc/rfc3875
"CGI local redirect not implemented correctly"
https://redmine.lighttpd.net/issues/2108
"1.4.40 regression: broken redirect (using Location) between url.rewrite-once URLs"
https://redmine.lighttpd.net/issues/2793

History

#1 Updated by gstrauss 12 months ago

  • Status changed from New to Patch Pending
  • Target version set to 1.4.40

#2 Updated by gstrauss 12 months ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

#3 Updated by Olaf-van-der-Spek 5 months ago

Does it make sense to alter / fix / break this behavior after decades?
I've been using redirects without scheme/host part for over a decade and wasn't aware of this 'rule'. What do other web servers do?
A redirect is frequently done after a POST, silently doing the redirect server-side has quite an affect.
Maybe this should be opt-in?

#4 Updated by gstrauss 5 months ago

Thanks for your comment. Please note that this change was released 6 months ago.

A patch was released in lighttpd 1.4.45 for better compatibility with redirects sent along with Set-Cookie.

No other issues have been reported in the past 6 months. If this change causes hardships for someone, yes, we will consider creating a config directive to disable the behavior.

#5 Updated by Olaf-van-der-Spek 5 months ago

gstrauss wrote:

Thanks for your comment. Please note that this change was released 6 months ago.

Yes, and?
Please note that not everyone has updated to a version including this change (yet).
For example, some systems won't be updated until after the next Debian version is released.

A patch was released in lighttpd 1.4.45 for better compatibility with redirects sent along with Set-Cookie.

I know, but it sounded like that didn't cover all cases.

No other issues have been reported in the past 6 months. If this change causes hardships for someone, yes, we will consider creating a config directive to disable the behavior.

#6 Updated by gstrauss 5 months ago

Your post provides no new information and is not helpful nor forward-looking.

Yes and?

#7 Updated by Olaf-van-der-Spek 5 months ago

Nevermind then

#8 Updated by stbuehler 4 months ago

  • Related to Bug #2793: 1.4.40 regression: broken redirect (using Location) between url.rewrite-once URLs added

Also available in: Atom