Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP header names are not unique #2

Open
KirkBrooks opened this issue Oct 3, 2024 · 2 comments
Open

HTTP header names are not unique #2

KirkBrooks opened this issue Oct 3, 2024 · 2 comments

Comments

@KirkBrooks
Copy link

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
Copy link
Owner

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
Copy link
Author

KirkBrooks commented Oct 9, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants