-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Use LoopbackServer for HttpWebRequestTests #37451
Use LoopbackServer for HttpWebRequestTests #37451
Conversation
da9fb56 to
9a2385c
Compare
stephentoub
left a comment
There was a problem hiding this 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.
|
@ViktorHofer Are you still working on this PR? |
|
Yes I'm willing to finish this but need a recommendation here: #37451 (comment) |
|
@stephentoub @davidsh for SSL I had to set |
9a2385c to
c732b84
Compare
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. |
|
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
stephentoub
left a comment
There was a problem hiding this 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.
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 |
|
All the tests are failing on UWP: |
|
Ping @davidsh, see question above |
I'm seeing errors in NETFX and UWP runs:
And the UWP failures as well:
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")] |
|
Thanks for the help @davidsh and @stephentoub. We should update the docs that mention the LoopbackServer at some point. |
Which docs? |
* Use LoopbackServer for HttpWebRequestTests Commit migrated from dotnet/corefx@d57a1a2

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.