To be clear, lowercase or all uppercase are all valid. Many resource servers parse the header with code like I shared.
The volume of LLM generated code is going to grow exponentially -- I was using Claude's latest version to get this result. Postel's Law: "Be conservative in what you send, be liberal in what you accept." The sample code is strict in what it accepts unfortunately. On Sun, Jul 6, 2025 at 6:34 PM Warren Parad <wpa...@rhosys.ch> wrote: > 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
