On Sat, Mar 30, 2019 at 11:50 AM <[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. >
That section defines the ABNF (Augmented Backus-Naur Form, a specification for defining syntax rules), and defines what character sequences are allowed for paths. When we indicate that the path must be valid, we are indicating it must be valid per the ABNF defined in that section. It is specifically NOT requiring that you validate that the path is valid _for the domain or the scheme_, only that it is well-formed. > 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 path segment of a URI has a single ABNF, as defined in the section you link. I'm not quite sure what you're inferring here, but I'm wondering if perhaps you're looking at a different specification? 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? > PSR-7 only defines URIs for the HTTP and HTTPS schemes. This was a very deliberate choice, as we felt defining something that was generic enough to fit any possible scheme was out-of-scope for a specification focusing on HTTP messages. As such, the ABNF for path specifications is the same, and there's no reason to revalidate the path. There was some talk at one point of creating a general specification for URI interface(s), but nobody has moved forward as far as a proposal at this point. -- 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_myXLA-Ce5MV6Tm%2BPd9%2B81SczpAc-_y2ppTZiBMoFsZn70g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
