URLManifestItem.url shouldn't contain non-URL-unit characters - #181
URLManifestItem.url shouldn't contain non-URL-unit characters#181gsnedders wants to merge 2 commits into
Conversation
Sorry, something went wrong.
|
(There's also the variant of this RFC where all we do is url.replace(" ", "%20") which avoids the "space separated URLs" problem. But it still carries the same risks.) |
Sorry, something went wrong.
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
Given how few such files there are, let's just disallow them. |
Sorry, something went wrong.
jgraham
left a comment
There was a problem hiding this comment.
Storing URLs (and therefore test ids) in url-encoded form does make sense.
Migrating expectation data is a challenge. I wonder if for the wpt expectation files (which handle spaces fine) we could just unencode the test id before using the manifest? That makes it more likely that the manifest will match whatever people write in the <meta name=varaint>. Alternatively if we're going to change to using the URL encoded form everywhere, I think we should have a lint to ensure we use it consistently (maybe we should have a lint either way, so that we don't get %20 in some places and in another).
I don't think banning spaces in test names is worthwhile.
Sorry, something went wrong.
I just searched for spaces in filenames and found two cases that don't seem intentional: web-platform-tests/wpt#46253 Is there much of a downside to banning spaces? |
Sorry, something went wrong.
Rendered