sec-fetch-dest header is defined as "email-verification"

[dickhardt]

But Chrome is sending sec-fetch-dest: emailverification

@samuelgoto -- WHATWG removes hyphens -- which is likely why Chrome has emailverification -- keeping the hyphen aligns the string with every where else it appears though

[samuelgoto]

I think this is a duplicate of this issue?

#16

But yeah, I do think that not having a dash is deliberate.

Cool if I close this as duplicate and we continue the conversation on the other one (or vice versa?)?

[samuelgoto]

WHATWG removes hyphens -- which is likely why Chrome has emailverification --

Yeah, we did ask around for whether we would want to keep the hyphenization consistent with other Sec-Fetch-Dest headers, and that's the guidance that we got indeed.

keeping the hyphen aligns the string with every where else it appears though

I agree, but then makes it inconsistent with the WHATWG guidance for Sec-Fetch-Dest.

I think, pragmatically, we have two choices:

1. remove the hyphenization everywhere or
2. leave the inconsitency between the Sec-Fetch-Dest header and the .well-known file and the DNS TXT record

It is not ideal, but given the constraints of the real world, I'm leaning towards (2).

WDYT?

[dickhardt]

inconsistent with the WHATWG guidance for Sec-Fetch-Dest

pointers on this?

[cbiesinger]

None of the other values contain a hyphen, even when they are two words. https://fetch.spec.whatwg.org/#concept-request-destination

[dickhardt]

@cbiesinger -- just because none of the other values in the spec use a hyphen does not seem like a good reason to add friction to a developer that is adding support for email-verification -- they don't care about other fetch strings -- they care about all the places they need to use email-verification. Consistency across the fetch spec should be subservient to developer ergonomics in getting it right for implementing a feature.

I was looking for s pointer to WHATWG guidance -- if it is just "all the others have no hyphen" that seems hard for me to rationalize to others.

[samuelgoto]

I was looking for s pointer to WHATWG guidance -- if it is just "all the others have no hyphen" that seems hard for me to rationalize to others.

@domfarolino @annevk are probably good POCs for the WHATWG guidance/preferences.

@domfarolino @annevk: any chance we could get sec-fetch-dest with hyphens for email-verification rather than emailverification. We picked emailverificaiton so that it is consistent with the other ones but that makes it inconsistent with the .well-known/email-verification that we are introducing and the DNS entry we are also setting up.

The three options I think we have are: (a) keeping sec-fetch-dest inconsistent with the rest of the protocol, (b) make sec-fetch-dest use email-verification or (c) make everything else in the protocol use emailverification rather than email-verification.

Because we go too far in (a) and (c) we wanted to ask you two: any chance it would be acceptable to make sec-fetch-dest take a hyphen and use email-verification or it the consistency with the other values critical to you?

[domfarolino]

In my opinion, there is no issue adding email-verification to the list of request destinations, and having the header Sec-Fetch-Dest: email-verification. It's true that no other value in that enumeration uses hyphens, but I feel like that's more of a function of the fact that things like serviceWorker, SharedWorker, and paintWorklet are all referenced as one "word" in the platform, and never separated by a hyphen or a space when developers reference them programmatically.

Email verification feels different to me, and especially since the way developers will reference this via the HTML attribute does use a hyphen, it probably makes sense to do the same in the header. We should note that a request's destination is web-exposed via the attribute getter, but this exposes strings in an enum, and hyphenating enum values is indeed consistent with the TAG design principles on casing (https://w3ctag.github.io/design-principles/#casing-rules).

So I personally think approach (b) makes the most sense here.

Yeah, we did ask around for whether we would want to keep the hyphenization consistent with other Sec-Fetch-Dest headers, and that's the guidance that we got indeed.

I would like to know if anyone provided guidance in the other direction, beyond just "we don't have hyphens in the other destination values", to make sure I'm not contradicting any known rule I'm not aware of. My understanding is that it was @cbiesinger who obtained this guidance from somewhere, so maybe he could give more details?

[samuelgoto]

So I personally think approach (b) makes the most sense here.

That sounds like great guidance @domfarolino ! I think that might be sufficient acknowledgement from a WHATWG HTML co-editor that I think would be enough for us to go in that direction. @cbiesinger LMK if you strongly disagree and we can course-correct.

I kicked off an implementation issue tracker here for chromium.