base URLs for iframes
Status: Beta
Brought to you by:
worden
Menu
▾
▴
#199 base URLs for iframes
I just coded in a new feature for .html project files. Previously it did the following with .html files:
On Special:GetProjectFile:
- if it's a fragment, i.e. doesn't have an enclosing "<html>", insert it into the special page's html.
- if it's a self-contained page, i.e. has an "<html>", display it on its own.
Embedded in a wiki page as a <project-file> element:
- if it's a fragment, insert it into the page's html
- if it's a self-contained page, strip away the enclosing html and stuff, and display the inner part with any relative URLs it contains rewritten.
I received an email asking why it doesn't work to include a complex html page that comes with software-generated .js and .css resources. The answer was because the base URL is wrong. Actually maybe that wasn't the answer but I thought it was.
So I change the behavior for including a full page into a wiki page to the following:
- display the full HTML file in an <iframe> element, with its url rewritten to something like http://domain.name/wikiname/index.php/Special:GetProjectFile/project=project/display=raw/make=no/filename. This allows relative URLs to work.
The problem is that certain arguments in that list might contain slashes. They get properly URL-encoded, so it should be fine, except some (many?) web servers don't accept URLs with encoded slashes, including ours. I worked around that in the case of preview data, but not in the case of project names with slashes.
Discussion
Anonymous
Would it also be a good idea to tell our server to accept these URLs?
not necessarily. I want to support as many server environments as possible without requiring people to jump through hoops - and changing that setting might not be an option on some people's servers without opening security holes. There's probably a better way to do this anyway.
Um, but if we end up having users inconvenienced because they want to do whizzy HTML stuff on subpages without waiting, we could enable that for a while...
I don't know, urlencoding and double-urlencoding the slash in a project name doesn't seem to work. It seems like maybe I'll try some kind of home-grown encoding, like maybe '\/'?
... that seems like it's working, at least in the one case I tried.
But for consistency, I should also replace '\' by '\\' then.
[Note: since I keep getting the formatting wrong on this thing, what I mean there is replace single backslashes by double backslashes.]