I think we should consider which pattern would more likely avoid security-related issues in the future.
I also would completely disregard all LLM generated code. It is an interesting heuristic for "the model got that suggestion from somewhere with high enough frequency", but arguably the simpler the spec, the easier it will be to generate compliant code by future LLMs. And also this will change as time goes on, as implementations are generated more successfully. We also know that most earth providers can't even follow the spec on it is today, creating their own custom things. It seems like being strick here in the spec is better than not. Just like HTTP2 has lowercase headers, I wound prefer bearer to also be lowercase, but I appreciate the breaking change that would require. "Being as permissible as possible" is not actually a good thing. On Sun, Jul 6, 2025, 19:23 Dick Hardt <dick.ha...@gmail.com> wrote: > Which code is badly written -- the one that has two spaces? or the one > that only parses a single space? > > On Sun, Jul 6, 2025 at 6:07 PM Thomas Broyer <t.bro...@gmail.com> wrote: > >> >> >> On Sun, Jul 6, 2025 at 6:57 PM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> Did you look at the code? (Its JavaScript) :) >>> >>> bearer will fail as the startsWith() is looking for 'Bearer' >>> >>> If there is a starting space >>> >> >> There's no such thing as a "starting space": >> https://datatracker.ietf.org/doc/html/rfc9110#name-field-values >> >> >>> or 2 spaces between Bearer and the token it will fail >>> >> >> So what? >> Are you suggesting changing a spec to please badly written/broken code‽ >> Also, what it is that you consider "widely deployed" in your first >> message? >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
