You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DECODE-URL parses the scheme part of an URL (before :) with the following charset:
A - Z a - z 0 - 9 + - . (this is in accordance with RFC 1738).
Then it does TO-LIT-WORD, which eliminates the case of an initial digit or + -, which seems to be allowed by RFC 1738.
TRANSCODE (i.e. the lexical scan) admits the following characters before the characteristic : of a URL! literal:
in initial position A - Z a-z ! & = ? * . ^ _ ` | ~ (note the absence of digits and+-).
In subsequent positions: anything from ! to ~ except [ ] { } ( ) " / :
Thus TRANSCODE is much more permissive than either RFC 1738 or DECODE-URL.
The restrictions mentioned would merit documenting, I think.
CC - Data [ Version: alpha 94 Type: Issue Platform: All Category: Datatype Reproduce: Always Fixed-in:none ]
The text was updated successfully, but these errors were encountered:
Submitted by: meijeru
DECODE-URL parses the scheme part of an URL (before :) with the following charset:
A - Z a - z 0 - 9 + - . (this is in accordance with RFC 1738).
Then it does TO-LIT-WORD, which eliminates the case of an initial digit or + -, which seems to be allowed by RFC 1738.
TRANSCODE (i.e. the lexical scan) admits the following characters before the characteristic : of a URL! literal:
In subsequent positions: anything from ! to ~ except [ ] { } ( ) " / :
Thus TRANSCODE is much more permissive than either RFC 1738 or DECODE-URL.
The restrictions mentioned would merit documenting, I think.
CC - Data [ Version: alpha 94 Type: Issue Platform: All Category: Datatype Reproduce: Always Fixed-in:none ]
The text was updated successfully, but these errors were encountered: