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 _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
