- From: Rory Hewitt <rory.hewitt@gmail.com>
- Date: Wed, 23 Jul 2025 10:10:14 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Darrel Miller <darrel@tavis.ca>, Atul Tulshibagwale <atul@sgnl.ai>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAEmMwDy-DUCQNO=5M9o6+ag+7_q-AH3Zp-2UzwzYq7YLWJWAeg@mail.gmail.com>
> I don't believe that is true. This was also my take - Structured Fields should be used where the field value is in any way 'complex', but if it's just a single value, it can (and maybe should) be used as-is. JWTs are a relatively new but also common standard and hence my suggestion that you simply define the Txn-Token field as a basic unquoted string which allows any characters, so it can be passed as: Txn-Token: eyJhbGciOiJ...mqJp-QV30 (on the assumption that the sender passes a valid JWT). Or you could define the field value as a valid JWT (three strings delimited by dots, with appropriate character sets for the two Base64 Url-encoded sections and for the key). Rory On Wed, Jul 23, 2025 at 9:51 AM Roy T. Fielding <fielding@gbiv.com> wrote: > On Jul 22, 2025, at 2:14 PM, Darrel Miller <darrel@tavis.ca> wrote: > > The current guidance is that all new HTTP fields are defined using > structured field values. > > > I don't believe that is true. > > If a new field would benefit from having a structured field value, > the usual suspects will ask for reasons why it isn't structured. That is, > structured fields have a known set of benefits for many potential > definitions > and the folks defining a new field may not be aware of those benefits. > > OTOH, there are many common fields for which structured field values > would be a waste of processing time and extra bytes on the wire. > Other usual suspects will ask for justification before wasting internets > on a syntax that isn't useful. > > Neither one is ensured by the current review process, which typically > allows > anyone to mint any field name with any arbitrary syntax, provided that > there > is some document that describes it. Not everything starts out as an I-D. > > IMO, the field described here is not suitable as a structured field value > because the structure has already been encoded as a token. I don't think > adding quotes around it is useful. > > Better questions are whether encoding the data as a token is a good idea, > given the alternative of using a structured list, and whether the data > contains credentials? > > https://www.rfc-editor.org/rfc/rfc9110.html#name-credentials > > Credentials belong inside the existing auth fields, not in extension > fields. > They need to be separated from other data to avoid compression and > other problematic handling/storage of extension fields. > > ....Roy > > -- Rory Hewitt https://www.linkedin.com/in/roryhewitt
Received on Wednesday, 23 July 2025 17:10:31 UTC