Item297: viewfile can't be used as a dropin replacement for {pubUrl}, and when viewfile fails it redirects to an oops mess
Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component:
Branches:
viewfile is broken
-
http://foswiki.org/bin/viewfile/Tasks/WebPreferences?filename=moderntimes.jpg
works
but what needs to work is to have
PUBURL
set to
SCRIPTURL{viewfile}
- ie
-
http://foswiki.org/bin/viewfile/Tasks/WebPreferences/moderntimes.jpg
and this is terminally busted, redirecting to
-
http://foswiki.org/bin/oops/Tasks/WebPreferences/moderntimes/Jpg?template=oopsattention;def=no_such_attachment;param1=viewfile;param2=moderntimes.jpg;template=oopsattention;def=no_such_attachment;param1=viewfile;param2=moderntimes.jpg
which makes no sense at all for what should be a 404, unless the user happens to be showing just that url.
the fact it redirects is really painful too - see the oops bug Crawford put in.
if it
did work this way, we could set pubUrl to use viewfile, and then use an apache rewrite to go directly to the file url for the System web. (for eg).
It seems that this problem is the same as
Item5967, that was fixed (I can't check now in what branch it was fixed).
yeah, you and I wish it were, but the change in trunk : see the link to trac in the Task, didn't address the bug, so I'm thinking it was a partial fix. I'm also not really happy about the location of the change.
I am planning on writing a bucket of tests, cos my commit doesn't fill me with confidence either.
- need to test nested webs,
- need to make sure the web&topic is correct
- need to make sure that is works out non topic paths - such as System/DojoToolKitContrib/A/long/file/path/to/Some.css
- and that with all these variations that the topic ACL's are respected.
given that Rob and I failed to test either of our fixes with enough variations - it must be automated. (ew)
Sven
ok, many tests added, and a working fix applied
--
SvenDowideit - 27 Nov 2008