You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support multiply query ResourceParameters with same name #63
Is your feature request related to a problem? Please describe.
There is currently now way to parse values for multiple parameters with the same key-name.
e.g. a valid query string could be: ?ctrarray=1&ctrarray=2&ctrarray=3&ctrarray=4 ... and getRequestParameter would always only return the first occurrence of the parameter.
This also occurs in POST forms where there are multiple input fields with the same name. e.g. when it's possible to enter multiple data rows with the same fields.
e.g.:
Describe the solution you'd like
This is sometimes used in the wild and can be useful in bare-bone microcontroller webpage environments. Most frameworks support it. It would thus be useful to iterate over the request parameters.
Describe alternatives you've considered
Not supporting this, since most people hopefully won't need to parse queries like this.
changed the title [-]Support full standard of query ResourceParameters[/-][+]Support multiply query ResourceParameters with same name[/+]on Dec 2, 2019
Do you know anything more current/more official on this topic than what's discussed in this answer on StackOverflow?
Returning a collection of strings from getRequestParameter would make processing the request parameters more complicated in most cases (at least that's what I'd assume), where this is not needed, and if the specification does not cover the way this should be handled, I'd not make the API more complicated than that.
Maybe it would be a solution to include the duplicate parameters when using the iterator from #62 to go through the request parameters? In that case the user can decide if duplicate values are relevant and define how they should be handled.
Nothing more authoritative that that. As it says, there does not seem to be a standard, thus everything that the schema allows is used somewhere, including the use of multiple identical keys. I know that a decade ago already some frameworks would translate array data to request-data in this form.
I think that mostly this will not be needed, so just including them in the iterator from #62 should be perfectly fine.
Activity
[-]Support full standard of query ResourceParameters[/-][+]Support multiply query ResourceParameters with same name[/+]fhessel commentedon Dec 3, 2019
Do you know anything more current/more official on this topic than what's discussed in this answer on StackOverflow?
Returning a collection of strings from
getRequestParameterwould make processing the request parameters more complicated in most cases (at least that's what I'd assume), where this is not needed, and if the specification does not cover the way this should be handled, I'd not make the API more complicated than that.Maybe it would be a solution to include the duplicate parameters when using the iterator from #62 to go through the request parameters? In that case the user can decide if duplicate values are relevant and define how they should be handled.
btittelbach commentedon Dec 3, 2019
Nothing more authoritative that that. As it says, there does not seem to be a standard, thus everything that the schema allows is used somewhere, including the use of multiple identical keys. I know that a decade ago already some frameworks would translate array data to request-data in this form.
I think that mostly this will not be needed, so just including them in the iterator from #62 should be perfectly fine.
Modify interface to query parameters. Close #62. Close #63
Modify interface to query parameters. Close #62. Close #63