[swift-corelibs-dev] NSHTTPURLResponse.localizedStringForStatusCode()

Philippe Hausler phausler at apple.com
Thu Mar 17 12:54:54 CDT 2016

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

More information about the swift-corelibs-dev mailing list