and got output (abbreviated to only significant lines truncated with […]):
> HEAD http://tinyurl.com/selfcontained-editable-datauri HTTP/1.1
< HTTP/1.1 308 Permanent Redirect
< Location: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTU[…]
* Issue another request to this URL: 'http://tinyurl.com/data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhU[…]'
> HEAD http://tinyurl.com/data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTU[…]
< HTTP/1.1 404 Not Found
I expected the following
I am not completely sure what exactly should happen, but certainly not request to HEAD http://tinyurl.com/data:text/[...], since data: is a scheme (denoting pseudo-protocol), not a path segment.
It would probably make sense to ignore all data URI scheme redirects, since attempt to load data URI directly fails:
λ curl "data:text/plain,test"
curl: (3) URL using bad/illegal format or missing URL
But if it was supported, then for regular non---location --head invocation I'd expect it should (in the first case) decode the base64 payload and then save resulting (text) content into file. (Question is, what name that file should have.)
This is probably a niche issue. This kind of redirect (as well as any kind of indirect navigation to DataURI documents) is nowadays blocked in web browsers altogether (or at least in top-level frames) for security reasons — sadly, DataURIs were reportedly heavily abused for scams — but in the past versions this particular HTML doodle "stored" in the TinyURL redirect worked: it loaded HTML "quine" document with text editor that could save itself back into DataURI. As of today it kinda works when loaded into sub-frame and only in Firefox, like:
When the parser is not allowed to guess scheme, it should consider the
word ending at the first colon to be the scheme, independently of number
of slashes.
The parser now checks that the scheme is known before it counts slashes,
to improve the error messge for URLs with unknown schemes and maybe no
slashes.
When following redirects, no scheme guessing is allowed and therefore
this change effectively prevents redirects to unknown schemes such as
"data".
Fixes#9503
When the parser is not allowed to guess scheme, it should consider the
word ending at the first colon to be the scheme, independently of number
of slashes.
The parser now checks that the scheme is known before it counts slashes,
to improve the error messge for URLs with unknown schemes and maybe no
slashes.
When following redirects, no scheme guessing is allowed and therefore
this change effectively prevents redirects to unknown schemes such as
"data".
Fixes#9503
I did this
and got output (abbreviated to only significant lines truncated with
[…]
):I expected the following
I am not completely sure what exactly should happen, but certainly not request to
HEAD http://tinyurl.com/data:text/[...]
, sincedata:
is a scheme (denoting pseudo-protocol), not a path segment.See: Data URI Scheme.
It would probably make sense to ignore all data URI scheme redirects, since attempt to load data URI directly fails:
But if it was supported, then for regular non-
--location --head
invocation I'd expect it should (in the first case) decode the base64 payload and then save resulting (text) content into file. (Question is, what name that file should have.)curl/libcurl version
curl 7.84.0
operating system
Windows 10 v21h2 b19044
Notes
This is probably a niche issue. This kind of redirect (as well as any kind of indirect navigation to DataURI documents) is nowadays blocked in web browsers altogether (or at least in top-level frames) for security reasons — sadly, DataURIs were reportedly heavily abused for scams — but in the past versions this particular HTML doodle "stored" in the TinyURL redirect worked: it loaded HTML "quine" document with text editor that could save itself back into DataURI. As of today it kinda works when loaded into sub-frame and only in Firefox, like:
The text was updated successfully, but these errors were encountered: