-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. The code was written to ease accessing the variables. Usually developer calls Still I think this collection of typical helper calls are targeting standard cases and not every exception. I keep the issue open, so users can see there are limitations. Thanks for reporting. |
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
<#2 (comment)>,
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
|
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
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.
The text was updated successfully, but these errors were encountered: