HttpURI.toURI() does not copy fragment

[ritzow]

Jetty version(s)

11.0.7

Java version/vendor (use: java -version)

Oracle OpenJDK 17 (from jdk.java.net)

OS type/version

Windows 10.

Description
The fragment does not get copied into the URI object, the final parameter in the URI constructor is set to null, even though HttpURI can handle fragments. This is very unexpected, and I assume, a bug.

https://github.com/eclipse/jetty.project/blob/cb127793e5d8b5c5730b964392a9a905ba49191d/jetty-http/src/main/java/org/eclipse/jetty/http/HttpURI.java#L242

How to reproduce?

HttpURI.build(request.getHttpURI()).fragment("a_fragment").toURI().toString() will produce a URI with no fragment.

[gregw]

It was/is kind of a deliberate bug. Browsers should never send a fragment to the server and as HttpURI is primarily a class used for our server to handle/manipulate URIs, we left the fragment out so that even if some non-browser client sent one, we would drop it and not copy it. This was done more so that we didn't have to think about any consequences of propagating a fragment in server rather than from any hard knowledge of a specific problem.

So can you tell us more about your use-case and why you need a fragment in HttpURI? If there us a real usage, then perhaps we can support it. If there is not, then we should at least document that we deliberately drop the fragment.

[ritzow]

@gregw Good to know. I was just going to use it in a Location header from the server side to have the browser automatically scroll to a specific tag, which appears to be accepted by all browsers and in the HTTP spec. I ended up just using specific HttpURI methods instead of HttpURI or URI toString() because it gives more control over the format anyways, but it would be good to at least have a javadoc comment on that method mentioning that it doesn't copy the fragment.

[joakime]

Just adding information (for others that see this in the future)

The HTTP protocol, be it HTTP/1.1 or HTTP/2 (or HTTP/3), basically says that the resource being requested is defined by the ABNF for path-absolute as defined by RFC3986: Section 3 with an optional query portion. (this definition for how the protocol is used never has a fragment uri-subcomponent)

See:

• HTTP/1.1 spec - Identifying a target resource - https://datatracker.ietf.org/doc/html/rfc7230#section-5.1
• HTTP/2 spec - :path pseudo header field - https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.3

The scheme-specific URI handling for http and https, defined in RFC7230, also says ..

The target URI excludes the reference's fragment component, if any,
since fragment identifiers are reserved for client-side processing

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.