Anonymous user
Talk:Find URI in text: Difference between revisions
Task and RFC are not aligned
(Task and RFC are not aligned) |
|||
Line 5:
:: So, since spaces can be entered in a browser, they can be accepted as part of a URI, here? --[[User:Rdm|Rdm]] 18:17, 5 January 2012 (UTC)
::: i suppose if the url has a delimiter like quotes or <http://go.here/to this place>, then i don't see why not. it's depends on the ability to figure out the users intent. and on the application. depending on where the parser is used there might even be an opportunity to verify that a url actually exists. (now that would actually be an interesting feature: you type some text on some website, and the browser or server tells you that the url you typed does not exist)--[[User:EMBee|eMBee]] 03:38, 6 January 2012 (UTC)
== What actually parses as a URI is not what is intended by the task author ==
I just had a look at this against the cited RFC. I believe the task description is inconsistent with the syntax spelled out in the RFC. For instance,
* Even though it doesn't make sense to a person "stop:" is a valid scheme and parses as a URI through 'path-empty'. To rule it out you must know what the valid schemes are.
* nothing in the RFC indicates that parenthesis must be balanced and the characters are allowed via the 'segment' parts of URIs.
Based on this a solution that gives "stop:" and containing unbalanced parenthesis are technically valid but probably not what the author intended. --[[User:Dgamey|Dgamey]] 02:17, 8 January 2012 (UTC)
| |||