Skip to content
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

Implement NSHTTPURLResponse #287

Merged
merged 1 commit into from Apr 14, 2016
Merged

Conversation

danieleggert
Copy link
Contributor

This implements both the trivial attributes (statusCode and allHeaderFields), and also parses the headers in order to set the following attributes:

public var mimeType: String? { get }
public var expectedContentLength: Int64 { get }
public var textEncodingName: String? { get }
public var suggestedFilename: String? { get }

Added tests for these.

The

public class func localizedStringForStatusCode(statusCode: Int) -> String { NSUnimplemented() }

method on NSHTTPURLResponse is still unimplemented.

@danieleggert
Copy link
Contributor Author

Note: This changes the type of allHeaderFields to [String : String] — I hope that's ok?

@phausler
Copy link
Member

That actually makes sense since the init method is NSDictionary<NSString *, NSString *> * headerFields.

It seems like that might just be an oversight for the property. I will follow up with that component owner to determine if it is actually the case that it can never be anything but strings.

@danieleggert
Copy link
Contributor Author

@phausler The same goes for NSURLSessionConfiguration’s HTTPAdditionalHeaders.

@@ -167,9 +178,9 @@ public class NSHTTPURLResponse : NSURLResponse {
@result A dictionary containing all the HTTP header fields of the
receiver.
*/
public var allHeaderFields: [NSObject : AnyObject] { NSUnimplemented() }
public let allHeaderFields: [String : String]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have a comment on why the differential and identifying it as an "experimental" change; albeit that I agree that this should be the signature, I have not yet heard back from the component owner on a definitive reason on either why it should or should not be marked as string to string.

@danieleggert
Copy link
Contributor Author

Thanks for the feedback. I’ve tried to address you suggesting with ae45629 and 82a818e. I’ll squash everything into a single commit if / once I get a green light.

@phausler
Copy link
Member

looks pretty good to me.

@danieleggert
Copy link
Contributor Author

Should this be assigned to @salgernon ?

@danieleggert
Copy link
Contributor Author

I rebased against master and squashed the 3 commits into a single commit.

@phausler
Copy link
Member

The tests seem to have some failures when it is tested against the objective-c version for me:

Test: test_contentLength_notAvailable_2() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional(997)") is not equal to ("Optional(-1)") - 
File: test.swift:174



Test: test_contentLength_notAvailable_3() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional(997)") is not equal to ("Optional(-1)") - 
File: test.swift:179



Test: test_contentLength_notAvailable_4() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional(997)") is not equal to ("Optional(-1)") - 
File: test.swift:184



Test: test_contentLength_notAvailable_5() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional(997)") is not equal to ("Optional(-1)") - 
File: test.swift:189



Test: test_MIMETypeAndCharacterEncoding_3() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional("iso-8859-4")") is not equal to ("Optional("ISO-8859-4")") - 
File: test.swift:265



Test: test_suggestedFilename_4() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional("wrong.ext")") is not equal to ("Optional("fname.ext")") - 
File: test.swift:234



Test: test_suggestedFilename_notAvailable_1() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertNil failed: "Unknown" - 
File: test.swift:208



Test: test_suggestedFilename_notAvailable_2() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertNil failed: "Unknown" - 
File: test.swift:213



Test: test_suggestedFilename_onlyTheLastPathComponent_1() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional("_a_b_name")") is not equal to ("Optional("name")") - 
File: test.swift:239



Test: test_suggestedFilename_onlyTheLastPathComponent_2() in TestNSHTTPURLResponse failed on My Mac
Assertions: XCTAssertEqual failed: ("Optional("a_.._b_name")") is not equal to ("Optional("name")") - 
File: test.swift:244

Test: test_suggestedFilename() in TestNSURLResponse failed on My Mac
Assertions: XCTAssertNil failed: "path" - 
File: test.swift:67

@danieleggert
Copy link
Contributor Author

The failure in test_suggestedFilename_4 looks like a bug in Darwin Foundation to me.

@danieleggert
Copy link
Contributor Author

I've addressed the difference to Objective-C Foundation with the 4 above commits.

@phausler
Copy link
Member

phausler commented Apr 4, 2016

I tend to agree that probably the failure of test_suggestedFilename_4 on Darwin is a bit un-expected; I will follow up with the networking team via radar on this. For now I would probably claim if that is the only differential it is an edge-case enough that it shouldn't hamper this PR.

@phausler
Copy link
Member

phausler commented Apr 4, 2016

@swift-ci Please test

@danieleggert
Copy link
Contributor Author

I’ll squash the commits into a single commit…

@parkera
Copy link
Member

parkera commented Apr 6, 2016

@swift-ci please test

@parkera
Copy link
Member

parkera commented Apr 14, 2016

@swift-ci please test

@parkera parkera merged commit be0a9c8 into apple:master Apr 14, 2016
///
/// - Important: This is an *experimental* change from the
/// `[NSObject: AnyObject]` type that Darwin Foundation uses.
public let allHeaderFields: [String: String]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't match the behavior of the real Foundation. Specifically, allHeaderFields uses a custom NSDictionary subclass that's case-insensitive when looking up keys. That case-insensitive behavior is pretty important behavior when dealing with HTTP headers.

It also canonicalizes certain headers, e.g. Content-Length, although it doesn't document which headers (besides Content-Length), and the canonicalization really only affects the case where you're displaying the header name so it's not really particularly important.

Given that Swift dictionaries are a value type and not a class, the only way we're going to get the same behavior while still using a dictionary type is to rely on bridging support and using an NSDictionary subclass, like the real Foundation does.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also note that this has to handle the case where the same header is provided with different capitalizations to the initializer (in that event, the resulting allHeaderFields dictionary should only contain one of the equivalent keys and its corresponding value, and the conflicts should be discarded).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Can you open a bug on that and assign it to me? Thanks.

@danieleggert danieleggert deleted the httpurlresponse branch April 15, 2016 09:35
atrick pushed a commit to atrick/swift-corelibs-foundation that referenced this pull request Jan 12, 2021
[test] Fix notification handler test when run in serial
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants