"The fragment percent-encode set is the C0 contr..."

[oneacik]

Hey,
could you check this issue in Tomcat?
It seems that your standard is used in browser but it doesn't fully comply to RFC
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273

Below the chunk:

https://url.spec.whatwg.org/commit-snapshots/a1b789c6b6c36fcdb16311da5abd177e84151fca/#percent-encoded-bytes

The fragment percent-encode set is the C0 control percent-encode set and U+0020 SPACE, U+0022 ("), U+003C (<), U+003E (>), and U+0060 (`).

[TimothyGu]

One of the Goals of the URL Standard is to

• Align RFC 3986 and RFC 3987 with contemporary implementations and obsolete them in the process. (E.g., spaces, other "illegal" code points, query encoding, equality, canonicalization, are all concepts not entirely shared, or defined.) URL parsing needs to become as solid as HTML parsing. [RFC3986] [RFC3987]

I'm not sure if this is something we want to align with the RFC, but from past experiences there are probably some good reasons why the spec is as it currently is. (In fact, query encoding is explicitly mentioned as one of the deviations.)

Also, Chrome is known to be lagging behind a lot of changes in the URL Standard. In this case it doesn't seem to matter, but otherwise it would be good to test with the unofficial reference implementation.

[annevk]

@oneacik I think you're talking about the rules in https://url.spec.whatwg.org/#query-state, right? At least, I didn't see URL fragments discussed in that Tomcat issue.

[oneacik]

the url like https://extranet.atlassian.com/recently-worked?prop={smth|evr} will render 400 because {|} are present in parameters. Firefox and Chrome will escape them only in address part not in parameters and tomcat (from 8.5.12) will drop it with 400 because.

@annevk I think yes.

[annevk]

Okay, so the problem here is that a URL client gets an invalid URL as input (possibly generates one with <form>?) and passes it on. I suspect we can't change that since most URL clients already interoperate on this and I'm pretty sure I've seen servers depend on this as well.

(Note that this already generates a validation error.)

[annevk]

Closing this as I don't think we can reasonably make breaking changes here.