I thought that a slash on the end of a web-address denoted that you were requesting the default resource at that URI.
However I guess that is a very HTTP-centric point of view.
So if the RFC leaves it open to interpretation, what does one do? Veer on the side of leniency?
Adam
On 04/01/2004 07:50 PM David Morris wrote:
Are you reading something into the spec? It seems like they are referring to a part of the URL. If not, I am wondering why the RFC shows examples in section E that do end in a slash.
"In practice, URI are delimited in a variety of ways, but usually within double-quotes "http://test.com/";, angle brackets <http://test.com/>, or just using whitespace
http://test.com/
These wrappers do not form part of the URI."
David Morris
[EMAIL PROTECTED] 4/1/2004 10:39:22 AM >>>
--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
-----Original Message-----
From: Adam Hardy [mailto:[EMAIL PROTECTED] Subject: Re: URL validation
On 03/15/2004 10:16 AM Adam Hardy wrote:
On 03/13/2004 07:46 AM [EMAIL PROTECTED] wrote:
From: Adam Hardy I provide URL validation on a page which
saves
links
for users.
I put together the latest build of commons-validator (1.1.2)
and
struts
(1.2) to see what the URL validation is like.
The class for server-side validation is in place, but the
javascript
doesn't exist.
It works very strictly, too strictly for me.
Most users will want to save links such as
http://www.google.com http://jakarta.apache.org/
http://marc.theaimsgroup.com/?l=struts-user&m=105511005106573&w=2
This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they
still
pass ? My guess is that it might not be expecting the '/' after the
domain
name. This would probably only require a small tweak to the regular expression thats used.
I would apply any patches that were submitted
Just got around to looking at a glitch in UrlValidator and I've
found
that the isValidPath() method explicitly fails when the path
(after
the
port number) is '/' - e.g.
http://www.google.com:80/?action=view expected:<true> but
was:<false>
The code actually does the following:
if (path.endsWith("/")) { return false; }
Surely this should not be so?
The way I read http://www.faqs.org/rfcs/rfc2396.html section 3.3
I don't believe the path segment can legally end with a '/'. Read the RFC and see what you think.
So I don't believe http://www.google.com:80/?action=xyz strictly speaking is valid, should we optionally allow for it
probably.
If we don't implement the RFC exactly, then we should probably add some sort of LENIENT flag to enable the non-standard behavior and make sure we document the exceptions to the standard well.
David
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
