search

ThomasMaul / Classes

collection of generic/useful classes
6 stars 1 forks source link

HTTP header names are not unique #2

Open KirkBrooks opened 1 month ago

KirkBrooks commented 1 month ago

https://github.com/ThomasMaul/Classes/blob/main/Project/Sources/Classes/tools.4dm

AccessWebVariables returns the headers as an object. This is fast but there are times when a header name may be duplicated.

RFC 7230 Section 3.2

A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).

A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.

Of course even the spec is not entirely specific. "The sender must not generate multiple header fields with the same field name..." except when they can and the recipient may, or may not, combine them in which case the order becomes significant.

There is also the issue of capitalization using field names for keys. I think in context, used primarily internally, it's not a problem. But applied more generally it can create results that are hard to analyze the source of. These are edge cases but that's where the bugs like to live.

ThomasMaul commented 1 month ago

Right. Code could fail like that.

It was written as helper method, to retrieve variables, such as used in HTML forms or REST post events. For variables, it is common to have unique names and transfer every variable just once, but right, if a post would contain several instances of the same variable, only the last one would be considered.

The code was written to ease accessing the variables. Usually developer calls WEB GET VARIABLES($anames; $avalues) to build two arrays, then use Find in Array to find the first occurance and then use that. The method was supposed to make just this easier. Then I had cases where the data was transfered inside body and not as HTML variable (as usual in REST API calls, not using HTML forms), so I thought same call could cover both. Again, in REST API calls variable names are usually unique, but nobody says it could not happen...

Still I think this collection of typical helper calls are targeting standard cases and not every exception. In case of an exception, it is better to use only WEB GET VARIABLES and arrays, not using an object.

I keep the issue open, so users can see there are limitations.

Thanks for reporting.

KirkBrooks commented 1 month ago

When I saw the example code using an object for the HTTP headers I was very excited. That makes it so easy and elegant. It was only after Claude informed me there were valid cases for duplicate headers I realized it wouldn't work long term.

On Tue, Oct 8, 2024 at 2:29 AM Thomas Maul @.***> wrote:

Right. Code could fail like that.

It was written as helper method, to retrieve variables, such as used in HTML forms or REST post events. For variables, it is common to have unique names and transfer every variable just once, but right, if a post would contain several instances of the same variable, only the last one would be considered.

The code was written to ease accessing the variables. Usually developer calls WEB GET VARIABLES($anames; $avalues) to build two arrays, then use Find in Array to find the first occurance and then use that. The method was supposed to make just this easier. Then I had cases where the data was transfered inside body and not as HTML variable (as usual in REST API calls, not using HTML forms), so I thought same call could cover both. Again, in REST API calls variable names are usually unique, but nobody says it could not happen...

Still I think this collection of typical helper calls are targeting standard cases and not every exception. In case of an exception, it is better to use only WEB GET VARIABLES and arrays, not using an object.

I keep the issue open, so users can see there are limitations.

Thanks for reporting.

— Reply to this email directly, view it on GitHub https://github.com/ThomasMaul/Classes/issues/2#issuecomment-2399338627, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGK5X7ESWS4MKXBOGPWFQ3Z2OQYZAVCNFSM6AAAAABPKDFPUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZGMZTQNRSG4 . You are receiving this because you authored the thread.Message ID: @.***>

-- Kirk Brooks San Francisco, California