Talk:URL parser: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 6: Line 6:


: That matches my reading of rfc2255 also. I'd say go for it (and mark the existing implementations with a task description updated tag). --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 14:36, 26 July 2015 (UTC)
: That matches my reading of rfc2255 also. I'd say go for it (and mark the existing implementations with a task description updated tag). --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 14:36, 26 July 2015 (UTC)

== hostname for arbitrary schemes ==

The introduction claims that arbitrary URI schemes (eg. foo://) should parse with full hostname, etc. However, [[User:Choroba]] claimed that "you don't get the host from the foo:// scheme, as host is only valid for schemes that define it." ([[URL parser#Perl|Perl section intro]]). One of these is incorrect, and should be amended. --[[User:Sondra.kinsey|Sondra.kinsey]] ([[User talk:Sondra.kinsey|talk]]) 16:00, 21 July 2016 (UTC)

Revision as of 16:00, 21 July 2016

= LDAP URL non-conformant

Great task! The example URLs provide good coverage, but the example ldap://[2001:db8::7]/c=GB?objectClass=one&objectClass=two is invalid per RFC2255. For solutions exercising library code that knows about more URL structures than HTTP, this is distracting. I suggest replacing it with the example in RFC3986: ldap://[2001:db8::7]/c=GB?objectClass?one which is just as parseable under HTTP rules, but won't blow up a parser that understands the ldap scheme.

--Aspectcl (talk) 03:59, 24 July 2015 (UTC)

That matches my reading of rfc2255 also. I'd say go for it (and mark the existing implementations with a task description updated tag). --Rdm (talk) 14:36, 26 July 2015 (UTC)

hostname for arbitrary schemes

The introduction claims that arbitrary URI schemes (eg. foo://) should parse with full hostname, etc. However, User:Choroba claimed that "you don't get the host from the foo:// scheme, as host is only valid for schemes that define it." (Perl section intro). One of these is incorrect, and should be amended. --Sondra.kinsey (talk) 16:00, 21 July 2016 (UTC)