--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > From: Adam Hardy [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 1, 2004 03:41 PM > > To: 'Struts Developers List' > > 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 > > http://www.google.com:80?action would be valid > http://www.google.com:80/path?action would be valid > > > > > > > Adam > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
