-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to sort out the behaviour for status_message with unknown status codes #114
Comments
Hi @robrwo , I am not entirely sure which RFC you are referring to when you mention «the RFC recommends some fallback values depending on the code range». For all I can read from RFC 7230, section 3.1.2 --- Status Line is:
and at the end of that section:
I'd like to emphasis "possible empty textual phrase". Then, in RFC 7232, section 6 --- Response Status Code:
In short:
So far, I have seen no «recommendation for some fallback value», I'm sorry Oh ... RTFRFC is something I showed in huge capitals during a presentation during YAPC Granada, so yes, I tend to be quite picky on these matter So far about your first statement... |
@robrwo , something next, you wrote «A problem is that some downstream modules that use this do not handle undefined values for this, which can cause further problems.» My first response is that it is their problem, the problem off the consuming code, not a problem caused by Secondly, the moment we are going to return anything but I'd rather not break the internet or any life code because of that change. As of your statement «We should be able to have default values, so that newer- or app-specific status codes can be used without having to break anything.» I'd say, again: Clients SHOULD ignore the reason phrase . And 'newer- or app-specific status codes' will simply work if one would follow the RFC recommendations. |
@robrwo 👍 ... «If there is a need to check for known status codes, that should be a separate function.» I would agree on that, but than in conjunction with something I worked on earlier in march and been rejected by @karenetheridge, for good reasons. I was trying to make it such that we would have separate Then anyone that needed to extend the list had a simple way of doing it. Official ones, would go not the official package, others could be included locally. I was thinking off something like: use HTTP::Status 'rfc7232'; or use HTTP::Status 'no rfc2324'; and default to: use HTTP::Status ':standard'; and then, yes it would be lovely to see print is_registerd('451'); # "rfc7725" that would be an awesome solution |
I'd suggest to make a new function:
Once we have that, we could add the my $message = status_message($code);
unless ($message) {
my $class_code = status_class($code);
$message = status_message($class_code);
croak "Status code not understood [$code], assuming class [$class_code] ($message)";
} or
I would feel way more comfortable reading these explicit things the a nifty default like NB. this could break the Oh... and if that is too much disrupting the calling code, one could always create there and then a local function sub status_message_with_fallback {
my $code = shift;
my $message = status_message($code) and return $message;
my $class_code = status_class($code);
$message = status_message($class_code);
croak "Status code not understood [$code], assuming class [$class_code] ($message)";
return $message;
} and the later: my $untrusted_message = status_message_with_fallback($code); Cheers |
okay, maybe I did approach it the wrong way, but I still will disagree with a new method that potentially will be the go-to thing for the future, since it's so easy to use. May I suggest a different approach, and rename your function to my $message = status_message($code);
unless ($message) {
$message = status_message_fallback($code);
croak "Status code not understood [$code], assuming ($message)";
} or my $message = status_message($code) || status_message_fallback($code); |
@oalders I'm unclear where we are on this.
The status_message should never be undef for a code between 100 and 599, and the RFC recommends some fallback values depending on the code range.
Only the numeric code value is to be used for understanding the response. The status code message is intended as a human-readable value, and the values given are standard defaults, but the web client is free to change it to be something else.
A problem is that some downstream modules that use this do not handle undefined values for this, which can cause further problems.
We should be able to have default values, so that newer- or app-specific status codes can be used without having to break anything.
If there is a need to check for known status codes, that should be a separate function.
The text was updated successfully, but these errors were encountered: