PSR-7 response status codes

[Korvin Szanto]

Hey Everyone,

I was wondering if we had any reasons to not include RFC 7231 status code constants on the ResponseInterface? If not, is this something we can add as errata?

Thanks,

Korvin

[Woody Gilk]

I'm not convinced that is really necessary. Check out https://github.com/lukasoppermann/http-status for a small package that deals only with status codes.

--
Woody Gilk
http://about.me/shadowhand

--
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/CANeXGWWfy2oP_3TfSu9Dz-TWj%2BF%3DfHfv8M7LDGtBf4HtyGgLvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Márk Sági-Kazár]

Another library that deals with status codes:

https://github.com/shrikeh/teapot/

[Korvin Szanto]

I don't think that we should need a second dependency to handle standard error codes that are explicitly defined by an RFC that we adhere to. These error codes are defined in the RFC and will never ever change without a new PSR so I don't see a reason we shouldn't include them on the interface.

This post is partly inspired by Phil Sturgeons blog post on the issue of hard coded status code integers: https://philsturgeon.uk/http/2015/08/16/avoid-hardcoding-http-status-codes/

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6%2Ba43iiLt8sC05ykdTN0vM-3RG-Q2p-cpo5r2Bn126LzQ%40mail.gmail.com.

[Matthew Weier O'Phinney]

On Mon, Nov 2, 2015 at 12:32 PM, Korvin Szanto <korvin...@gmail.com> wrote:

> Hey Everyone,
> I was wondering if we had any reasons to not include RFC 7231 status code
> constants on the ResponseInterface?

Yes: because they can change. :)

While the IETF contains a list of known/accepted status codes, any
unreserved codes can be co-opted at any time by end-users in order to
communicate more specific status. Since the specification is
extensible in this way, we're supporting only the minimal accepted
definition (the range of allowed status codes).

> If not, is this something we can add as
> errata?
>
> Thanks,
> Korvin
>

> --
> 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/CANeXGWWfy2oP_3TfSu9Dz-TWj%2BF%3DfHfv8M7LDGtBf4HtyGgLvg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



--

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

[Andreas Möller]

There's also 

* https://github.com/shrikeh/teapot

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6%2Ba43iiLt8sC05ykdTN0vM-3RG-Q2p-cpo5r2Bn126LzQ%40mail.gmail.com.

[Korvin Szanto]

On Mon, Nov 2, 2015 at 11:34 AM Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:

On Mon, Nov 2, 2015 at 12:32 PM, Korvin Szanto <korvin...@gmail.com> wrote:
> Hey Everyone,
> I was wondering if we had any reasons to not include RFC 7231 status code
> constants on the ResponseInterface?

Yes: because they can change. :)

While the IETF contains a list of known/accepted status codes

I'm only recommending we provide constants for the status codes defined in RFC 7231 section 6 [1] that we already declare compliance with.

 

any unreserved codes can be co-opted at any time by end-users in order to
communicate more specific status. Since the specification is
extensible in this way, we're supporting only the minimal accepted
definition (the range of allowed status codes).

 

Do we define any status codes today? The only requirements I see on the setStatusCode interface is that the code contains three digits. 

I don't mean to suggest that we change any wording here at all, I just want to add constants to the response object for the RFC 7231 defined status codes that we know are never going to change, I don't see any reason why we can't have something like:

$response->setStatus($response::STATUS_OKAY);

While still supporting the custom codes and the hardcoded codes:

$error_response->setStatus(999, 'Custom Error');

// or

$okay_response->setStatus(200); 

 

[1] https://tools.ietf.org/html/rfc7231#section-6

Thanks for the responses!

Korvin

[Alexander Makarov]

It's OK to do, I think. Additional codes such as custom REST meanings could be defined in implementing class.