When browsers build query strings for, say, multiselect inputs, they simply repeat the key with the new value. That's why, when sending forms to PHP, you have to set the name of such fields to end in `[]` - the way PHP deserializes query strings only preserves the last value unless you tell it to stuff them in an array. So while there isn't exactly a "canonical" way to serialize duplicate keys, I'd probably follow the browsers' lead and add them all as `key=value1&key=value2&key=value3&...`, and let the developer worry about making sure to use `key[]` for the names when necessary.
On Thu, Apr 4, 2019, 08:40 Matthew Weier O'Phinney <[email protected]> wrote: > > > On Thu, Apr 4, 2019 at 6:44 AM <[email protected]> wrote: > >> Okay thanks. Mine implementation is going to be a general implementation, >> but with http/https/ftp/sftp the same path rules apply so what I'm doing is >> throwing an exception if changing to scheme where the path no longer >> validates. >> >> One question still remains on key=value query normalization, I can't seem >> to find an RFC on it or even a best practices for when there are duplicate >> keys. >> It seems some give priority to first, some give priority to last, some >> serialize them as a key=[value1,...,valueN] comma delimited array, some >> only do the array thing if the were presented as key=[value1]&key=[value2] >> >> Is there any kind of RFC or best practices guide for dealing with >> key=value pairs in the context of GET query? >> >> Obviously for the email scheme one can't serialize them as an array, but >> for HTTP/HTTPS they potentially could be and sometimes are, I just don't >> know if that is a frowned upon practice or not or what is *suppose* to be >> done. Currently I just throw an InvalidArgument exception for duplicate >> keys but if there are normalization rules I would rather follow them. >> > > IIRC, IETF 3986 says that how they are normalized is up to the consumer > (which could be the server, php-fpm, a library, etc.) > > Maybe see what PHP's parse_str() does? > > > On Saturday, March 30, 2019 at 9:50:18 AM UTC-7, [email protected] >> wrote: >>> >>> Blocker Confusion - >>> >>> The interface method: >>> >>> public function withPath($path); >>> >>> requires >>> >>> * @throws \InvalidArgumentException for invalid paths. >>> >>> However in https://tools.ietf.org/html/rfc3986#section-3.3 I do not see >>> what constitutes an invalid path. >>> >>> Is that a bug in the interface or it it expected that the class validate >>> the path according to the RFCs specific to each scheme? >>> >>> The problem I have with the latter interpretation is twofold: >>> >>> A) It makes it impossible to create a class that is generic in scope for >>> scheme, which means if class A implements the interface and class B >>> implements the interface you can't just swap class A for B in use because >>> they may implement different schemes. >>> >>> B) The "withScheme($scheme)" method requires producing an identical >>> instance where only the scheme has changed, but that may then result in a >>> new instance where the path is not valid for that particular scheme because >>> all the other properties of the class must be retained. >>> >>> So... are we really suppose to validate the path according to the RFC >>> for the scheme or would it be better to leave validation of the the path >>> part of the URI to tools specific to the scheme by the software that uses >>> the class to build a URI? >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/85e91d49-aa8d-4567-92c4-3649d42ba2b1%40googlegroups.com >> <https://groups.google.com/d/msgid/php-fig/85e91d49-aa8d-4567-92c4-3649d42ba2b1%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Matthew Weier O'Phinney > [email protected] > https://mwop.net/ > he/him > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAJp_myWyTTggWg1doiafXMSu4mtALPTLgUOY1YLA%3DPFvTrkm8Q%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAJp_myWyTTggWg1doiafXMSu4mtALPTLgUOY1YLA%3DPFvTrkm8Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFjuE%2BmQa0QLWUGc-3xag_sQBLTPSJoofXYG8-FpufGh_S7vmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
