[PSR-7] UriInterface clarification or errata ?

107 views
Skip to first unread message

ignace nyamagana

unread,
Mar 28, 2015, 3:52:50 AM3/28/15
to php...@googlegroups.com
Hi Everyone,

I've been in the process to implement PSR-7 UriInterface in the upcoming league/url new version. I think there's a typo/errata on how the scheme is handle in accordance to the RFC3986

the withScheme method accepts scheme in form of "scheme://" while I understand the loose acceptance I think we should only accept "scheme:" as the trailing "//" is in fact a part of the formatted authority part of an Uri according to the RFC (RFC3986 section 3.2) and not part of the scheme at all. Removing the trailing "//" from the docblock would fix the issue IMHO while leaving them would imply that withScheme methods accept incorrect scheme pattern.

Matthew Weier O'Phinney

unread,
Mar 30, 2015, 11:20:06 AM3/30/15
to php...@googlegroups.com
Just a clarification: the withScheme() and getScheme() methods
indicate that *if* "://" is part of the scheme value stored, it must
be trimmed off. If the value is not present, then nothing needs to
change.

While the double slash is addressed in section 3.2, it's intended as a
separator between the scheme and the authority; interestingly, that's
also the purpose of the colon suffix on the scheme. The former acts as
a start signal, the latter as a terminator. In otherwords: ":", "//",
and "://" are separators between the scheme and authority, and
typically occur _together_.

As such, I think the clarification needed is that if the scheme ends
with *either* ":" *or* "://", those values should be trimmed. In other
words, it's not wrong currently, but needs to address the additional
case of presenting only the terminating character of the scheme.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Dracony

unread,
Mar 30, 2015, 12:14:55 PM3/30/15
to php...@googlegroups.com
I also have the question about the UriInterface. In your implementation you provide filtering for path. query ,etc. Is that something the interface should do? If so why is that not reflected in the comment?
Can an implementation throw an exception if those are imporperly formatted instead ? e.g. if a query contains an unescaped space or smth

Matthew Weier O'Phinney

unread,
Mar 30, 2015, 1:22:26 PM3/30/15
to php...@googlegroups.com
On Mon, Mar 30, 2015 at 11:14 AM, Dracony <draco...@gmail.com> wrote:
> I also have the question about the UriInterface. In your implementation you
> provide filtering for path. query ,etc. Is that something the interface
> should do? If so why is that not reflected in the comment?

Likely my docblocks in phly/http are not updated to the last revision
of the spec, but it *is* reflected in the docblocks within the
UriInterface:

The implementation MUST percent-encode reserved characters as
specified in RFC 3986, Section 2, but MUST NOT double-encode any
characters.

The above paragraph is included in each of withPath(), withQuery(),
and withFragment().


> Can an implementation throw an exception if those are imporperly formatted
> instead ? e.g. if a query contains an unescaped space or smth

Yes; again, the spec indicates that `InvalidArgumentException` can be
thrown in the case of invalid input.
> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/132c3341-5dc3-4605-a510-379a13dd4c72%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

Dracony

unread,
Mar 30, 2015, 1:32:03 PM3/30/15
to php...@googlegroups.com
Ah indeed, thanks.

Matthew Weier O'Phinney

unread,
Mar 31, 2015, 4:58:23 PM3/31/15
to php...@googlegroups.com
I've created a pull request for an errata to consider post-acceptance:

- https://github.com/php-fig/fig-standards/pull/480
Reply all
Reply to author
Forward
0 new messages