Fragment preservation is overly broad about http-core

[reschke]

It says what it says because UAs differed in what they were doing.

The HTTP specs predate Fetch. If you want a change in the HTTP specs, it would be good if you could explain why Fetch differs from browser navigation in behavior.

[annevk]

Differed how?

[reschke]

In whether they were applying the fragment, and how they recombined them. See https://trac.ietf.org/trac/httpbis/ticket/43.

[annevk]

It seems you didn't actually test the various scenarios outlined in OP (and curiously you only tested browsers, not other clients).

[annevk]

I think I do somewhat agree with your assessment in that issue that it's better to leave this up to a higher level in the stack as HTTP just relays fragments, but doesn't really do anything with them.

[annevk]

Note that this can likely be closed as I was mistaken to some extent: whatwg/fetch#505 (comment).

[annevk]

And to be clear, my plan of record is to make Fetch and HTML depend on HTTP defining the fragment handling, so if you do plan to leave it to a higher layer at some point, let Fetch know.

[mnot]

@annevk so we're good to close this one?

[annevk]

I guess you can close it, but it's not actually solved end-to-end yet. Changes haven't landed downstream, and clients haven't changed either. The longer the latter is true the more likely this will bubble back up and has to be revisited.

[reschke]

I'm still not sure what possibly would need to be "revisited".

The spec says what it says because people complained that 2616 didn't specify this. Years ago, we did the testing and got browsers to agree what to do on page navigation, and wrote that down.

What exactly do you think might be left to do?

[annevk]

Navigation isn't the only place where fragments are relevant (and HTTP doesn't restrict itself to navigation).

[mnot]

OK, closing. We can reopen if an action is needed.