publish location ending in a '/' should not be trimmed

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Composer
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: sujay, Assigned: Charles Manske)

Tracking

Trunk
mozilla1.0

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: publishing)

(Reporter)

Description

16 years ago
publish location not ending in a '/'
it really should

a directory *always* ends in a slash (otherwise you couldn't tell if it was a 
filename without an extension or a directory)
(Assignee)

Comment 1

16 years ago
nope. In order to control the madness of always checking for "/" at the end 
of directories, we have these rules:
1. The "publish" and "browse" urls in the dialogs (and in prefs) never have the 
terminal "/"
2. Whenever we publish, we *always* append the "directory" you see in the 
Publish panel of the Publish dialog. That string *always* begins and ends with
"/" (it may simply be "/" for the "root" directory of a site)
When you publish, the full destination URL is:
publishUrl + /directory/ + filename
thus we are guarenteed to always have the proper "/" 
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 2

16 years ago
Reopen

Users expect publish locations to end in a slash.
In reality, if there isn't a slash, you really can't tell if it's a directory or
a file.  Our UI needs some smarts to always add a slash on the end.

I don't care about the prefs, but the UI needs to be consistent with what users
are told by their ISP or other hosting service.  Removing the slash will confuse
them.

As for your second point, I'll argue that the publish / browse locations should
end in a slash (as above) and the Directory edit field in more should NOT begin
with a slash.  A leading slash there will lead some people to think "root of the
file system" or root of the server (like a relative url).

I think we should require an ending slash in publish/browse location edit
fields.  The other directory publish fields should end with a slash (if there is
any data in them).
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 3

16 years ago
Daniel gave me this example of for publishing:
  http://www.myhost.com/helpers/publish.cgi.file=filename.htm

After further discussion with Daniel, I believe we should always and
automatically add a slash to the publish location when it doesn't end in one of
these characters:  & = ? /
OS: Windows 98 → All
Hardware: PC → All
Summary: publish location not ending in a '/' → publish location ending in a '/' should not be trimmed
(Assignee)

Comment 4

16 years ago
ok, whatever. Just wish we decided that before.
Status: REOPENED → ASSIGNED
Keywords: nsbeta1+
Whiteboard: publishing
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 5

16 years ago
brade, glazman: If we are allowing funky publish urls that end in "&", "=", 
or "?", do you know if a filename with a "subdirectory" is allowed with those? 
E.g., would  http://www.myhost.com/helpers/publish.cgi.file=myfiles/filename.htm
work?
(Assignee)

Comment 6

16 years ago
Fixed as part of patch to bug 88208
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 7

16 years ago
Verified.   On the 03-08 trunk build, I am getting the ending / in the publish 
location.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

16 years ago
I also verified this is fixed in today's 3/8 trunk build.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.