Item5914: TWiki::Request::url() must support -rewrite, -absolute and -relative

pencil
Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component:
Branches:
Reported By: TWiki:Main.GilmarSantosJr
Waiting For:
Last Change By: GilmarSantosJr
Item2525 and Item5408 are enough evidence that TWiki::Request::url() must support -rewrite, -absolute and -relative and achieve complete CGI.pm compatibility.

-- TWiki:Main/GilmarSantosJr - 10 Aug 2008

-absolute support is easy to add (it's the same as $TWiki::cfg{ScriptUrlPaths}{$action} or $TWiki::cfg{ScriptUrlPath}/$action), since -rewrite is not added. The problem with -rewrite is that it depends on REQUEST_URI environment variable, that is not CGI-standard (working with the assumption that it's present cuts portability [not all webservers would implement and give the same semantics to it] and ties TWiki to CGI engine).

Item5408 is not specific why TablePlugin should be aware of rewrites and I can't figure out a good reason.

-- TWiki:Main/GilmarSantosJr - 11 Aug 2008

I added support for -absolute. I thought about -rewrite and IMHO admins should set $TWiki::cfg{ScriptUrlPath} and related according to their setups (with or without redirects). If we add a dependency on REQUEST_URI variable, things will work on Apache and CGI, but there's no guarantee about other webservers and engines. So, I choose portability and standards-compliance. Waiting for feedback from TWiki community.

-- TWiki:Main/GilmarSantosJr - 11 Aug 2008

This is one we need to discuss at a release meeting.

-- TWiki:Main.KennethLavrsen - 18 Sep 2008

I'll try to add support for -rewrite if the web server defined REQUEST_URI. I hope that all web servers that support rewrite rules also defines the non-standard REQUEST_URI (and I hope all of them use the same semantics). Probably it's fair to assume this, since CGI works this way.

-- TWiki:Main.GilmarSantosJr - 04 Oct 2008

I've studied CGI code a lot to understand -rewrite option. It takes place when REQUEST_URI doesn't begin with SCRIPT_NAME. That makes sense, except that I simply couldn't reproduce such a situation. I played with apache mod_rewrite a lot and always the REQUEST_URI starts with SCRIPT_NAME, I mean, -rewrite code is not executed.

Then I realized that even if I could reproduce this situation, it would not be that useful: I could generate correct links for the same script that is being executed, but not others. That's why $TWiki::cfg{ScriptUrlPath} and $TWiki::cfg{ScriptUrlPaths}{*} exist, so I generate URL's based on those settings (I also ignore SCRIPT_NAME, or almost this: I use it only to set $request->action). Those settings should be adjusted by admins considering rewrite rules.

TWiki:Main.RafaelAlvarez showed a situation that this mechanism doesn't work well: TWiki is installed behind a corporate firewall. Internally it is accessed using one URL. Externally another. If I generated URLs based on SCRIPT_NAME, then they would work well only for the action in use (I would correctly generate view when a topic was being viewed and correct edit when being edited), that is not enough IMHO.

So I'm closing this item with this limitation, that is not only on TWiki::Request but also in the way TWiki generates its URLs.

A possible solution for cases like Rafael's would be to make it possible to adjust $TWiki::cfg{ScriptUrlPath} based on the HTTP_HOST, for example (if the internal access is made using a virtual host different from external accesses), but then it's not a bug but a feature proposal.

-- TWiki:Main.GilmarSantosJr - 05 Oct 2008

Setting to Closed, since it's about new code.

-- GilmarSantosJr - 08 Jan 2009

ItemTemplate edit

Summary TWiki::Request::url() must support -rewrite, -absolute and -relative
ReportedBy TWiki:Main.GilmarSantosJr
Codebase
SVN Range TWiki-5.0.0, Sun, 03 Aug 2008, build 17280
AppliesTo Engine
Component
Priority Urgent
CurrentState Closed
WaitingFor
Checkins TWikirev:17402 TWikirev:17582
TargetRelease patch
ReleasedIn 1.0.0
Topic revision: r12 - 08 Jan 2009, GilmarSantosJr
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy