Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Conversation

@ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented May 5, 2019

Fixes https://github.com/dotnet/corefx/issues/22849
Fixes https://github.com/dotnet/corefx/issues/37430

Enabling a few tests which weren't running.

I left the synchronous tests as they were as I wasn't sure what the pattern for testing with the LoopBackServer synchronously is.

@ViktorHofer ViktorHofer requested review from davidsh and stephentoub May 5, 2019 16:06
@ViktorHofer ViktorHofer self-assigned this May 5, 2019
@ViktorHofer ViktorHofer force-pushed the HttpWebRequestTestLoopback branch from da9fb56 to 9a2385c Compare May 5, 2019 21:53
Copy link
Member

@stephentoub stephentoub left a comment

Choose a reason for hiding this comment

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

Thank you for working to move a bunch of these to loopback.

@davidsh
Copy link
Contributor

davidsh commented May 28, 2019

@ViktorHofer Are you still working on this PR?

@ViktorHofer
Copy link
Member Author

Yes I'm willing to finish this but need a recommendation here: #37451 (comment)

@ViktorHofer ViktorHofer requested a review from stephentoub May 29, 2019 13:26
@ViktorHofer
Copy link
Member Author

ViktorHofer commented May 29, 2019

@stephentoub @davidsh for SSL I had to set request.ServerCertificateValidationCallback = (a, b, c, d) => true; so that the validation check for the local certificate is skipped. Is that right or am I expected to trust the certificate on my box?

@ViktorHofer ViktorHofer force-pushed the HttpWebRequestTestLoopback branch from 9a2385c to c732b84 Compare May 29, 2019 13:30
@davidsh
Copy link
Contributor

davidsh commented May 29, 2019

@stephentoub @davidsh for SSL I had to set request.ServerCertificateValidationCallback = (a, b, c, d) => true; so that the validation check for the local certificate is skipped. Is that right or am I expected to trust the certificate on my box?

We don't want tests to rely on machine configuration (like setting a test certificate to be trusted on a dev box). So, yes, use the callback you showed. There are some exceptions to this rule for some detailed TLS testing we do, but for these tests we just want to exercise TLS.

@ViktorHofer
Copy link
Member Author

OK great, then this PR should be ready to go in. Please take another look. Thanks.

string strContent = sr.ReadToEnd();
Assert.True(strContent.Contains(RequestBody));
}
}, server => server.HandleRequestAsync(content: RequestBody), options);
Copy link
Member

Choose a reason for hiding this comment

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

This isn't right. The previous version was using an echo server, and by the client code checking that the response contained the request body, it was thus checking that the request body was correctly sent to the server (which then echo'd it). This change is making it so that the server simply ignores the request body and instead simply sends back the same content, without verifying that's actually what it received.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @stephentoub on this point. HttpWebRequest builds on HttpClient and we already have detailed tests for the HttpClient layer. So, we use these HttpWebRequest tests mainly to verify end-to-end functionality. And using an echo server helps satisfy that requirement.

Assert.True(headersString.Contains(headersPartialContent));
}
Assert.Equal(HeadersPartialContent, response.Headers[HttpResponseHeader.ContentType]);
}, server => server.HandleRequestAsync(headers: new HttpHeaderData[] { new HttpHeaderData("Content-Type", HeadersPartialContent) }), options);
Copy link
Member

Choose a reason for hiding this comment

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

Same echo server issue. It seems like we should add a server.Echo() method that functionally does the same thing the remote echo server was doing.

Copy link
Member

@stephentoub stephentoub left a comment

Choose a reason for hiding this comment

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

Generally looks good, a few nits, but two real issues. I suggest you revert the changes to the two problematic tests I commented on and get the rest of the changes merged. Then we can revisit needing a loopback server echo function.

@ViktorHofer
Copy link
Member Author

I suggest you revert the changes to the two problematic tests I commented on and get the rest of the changes merged

I implemented the echo functionality inline in the two tests as I thought it would be less work. After playing around with the server I noticed that the connection.ReadToEndAsync call doesn't read until the end but only the chunked part that was transmitted at that point. Instead I'm now reading from the stream directly...

@ViktorHofer
Copy link
Member Author

All the tests are failing on UWP: System.IO.IOException : Authentication failed because the remote party has closed the transport stream.. Am I missing something? The other failures are unrelated.

@ViktorHofer
Copy link
Member Author

Ping @davidsh, see question above

@davidsh
Copy link
Contributor

davidsh commented May 31, 2019

Ping @davidsh, see question above

I'm seeing errors in NETFX and UWP runs:

NETFX:
image

Unhandled Exception of Type System.ArgumentException
Message :
System.ArgumentException : The 'Content-Type' header must be modified using the appropriate property or method.
Parameter name: name

And the UWP failures as well:

All the tests are failing on UWP: System.IO.IOException : Authentication failed because the remote party has closed the transport stream.. Am I missing something? The other failures are unrelated.

I think the UWP failures are due to a limitation of trying to do loopback w/ TLS/SSL in the UWP environment. The tests worked fine using a remote server with TLS. But loopback in UWP is always problematic due to running under app container. I'm not sure what the exact problem is though without investigating it.

I don't think there is value in spending a lot of time on this since it is some kind of test bug/limitation with UWP. So, I would recommend you add this to those tests to skip it on UWP:

[SkipOnTargetFramework(TargetFrameworkMonikers.Uap, "Loopback server with TLS has problems on UWP")]

@ViktorHofer ViktorHofer merged commit d57a1a2 into dotnet:master Jun 2, 2019
@ViktorHofer ViktorHofer deleted the HttpWebRequestTestLoopback branch June 2, 2019 16:13
@ViktorHofer
Copy link
Member Author

Thanks for the help @davidsh and @stephentoub. We should update the docs that mention the LoopbackServer at some point.

@stephentoub
Copy link
Member

We should update the docs that mention the LoopbackServer at some point

Which docs?

@ViktorHofer
Copy link
Member Author

@karelz karelz added this to the 3.0 milestone Jul 16, 2019
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
* Use LoopbackServer for HttpWebRequestTests


Commit migrated from dotnet/corefx@d57a1a2
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

4 participants