NSHTTPURLResponse.localizedStringForStatusCode()


(Ian Partridge) #1

Hi,

A quick question about implementing this method.

Do we want the strings returned to match those returned by the
Objective-C implementation of Foundation, or follow RFC 2616?
Currently they are inconsistent, e.g. Obj-C Foundation returns "no
error" for status code 200, whereas the RFC says this is "OK".

The Obj-C implementation also returns strings for invalid status
codes, instead of the empty string. For example, if you ask for
status code 666 (an invalid code) you get "server error".

My instinct is we should start afresh and follow the RFC, as people
are unlikely to be relying on the content of these strings.

Thanks for your time!

···

--
Ian Partridge


(Philippe Hausler) #2

Well the interesting part here is that it is a localized string for a status code, so these should be a human readable output intended for display. If they were just stringForStatusCode then I would agree they should match the RFC, but since it is localized I think we shouldn’t try and reimplement as something completely different if at all possible.

That all being said; if they don’t match 100% it isn’t such a big deal since they are just intended for display and nothing programmatic so no one _should_ be relying on the values...

···

On Mar 17, 2016, at 10:27 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi,

A quick question about implementing this method.

Do we want the strings returned to match those returned by the
Objective-C implementation of Foundation, or follow RFC 2616?
Currently they are inconsistent, e.g. Obj-C Foundation returns "no
error" for status code 200, whereas the RFC says this is "OK".

The Obj-C implementation also returns strings for invalid status
codes, instead of the empty string. For example, if you ask for
status code 666 (an invalid code) you get "server error".

My instinct is we should start afresh and follow the RFC, as people
are unlikely to be relying on the content of these strings.

Thanks for your time!

--
Ian Partridge
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Ian Partridge) #3

Hi Philippe, thanks for your quick reply.

The HTTP status code reason phrases are designed to be human readable.
They are standard phrases that are easily searched for online.

The latest table is at
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
- isn't there a case for bringing the implementation of
.localizedStringForStatusCode() up to date with the latest specs?

Best wishes,

···

--
Ian Partridge


(Daniel Eggert) #4

What code will be used to make then _localized_?

/Daniel

···

On 17 Mar 2016, at 19:15, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi Philippe, thanks for your quick reply.

The HTTP status code reason phrases are designed to be human readable.
They are standard phrases that are easily searched for online.

The latest table is at
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
- isn't there a case for bringing the implementation of
.localizedStringForStatusCode() up to date with the latest specs?

Best wishes,

--
Ian Partridge
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Ian Partridge) #5

Good question - I wondered if Obj-C foundation translated them based
on the current locale, but it doesn't. They seem to be fixed
strings.

By the way, some more strangeness I spotted in the output of:

for i in 1..<1000 {
    print("\(i) " + NSHTTPURLResponse.localizedStringForStatusCode(i))
}

on Obj-C Foundation.

600 returns the empty string! Output is at
https://gist.github.com/ianpartridge/2d34e29d97b42c260931 - have a
look...

···

On 17 March 2016 at 19:31, Daniel Eggert <danieleggert@me.com> wrote:

What code will be used to make then _localized_?

--
Ian Partridge


(Quinn “The Eskimo!”) #6

I wondered if Obj-C foundation translated them based
on the current locale, but it doesn't.

It should translate them based on the current language (not locale). The fact that it doesn't is a bug. This seems to be yet another thing that got dropped when the code moved from Foundation to CFNetwork.

600 returns the empty string!

Yeah, that's definitely an off-by-one bug in the code.

I've filed <rdar://problem/25236188> to track the Objective-C side of this issue.

Share and Enjoy

···

On 17 Mar 2016, at 19:52, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware