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. 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. For more options, visit https://groups.google.com/d/optout.
