HttpClient ReadAsync waits for whole buffer to fill up even if HttpCompletionOption.ResponseHeadersRead is set

[ppekrol]

Hi,

I've prepared a simple project to demonstrate my issue:
https://github.com/ppekrol/ReadAsyncIssue

Steps to reproduce:

1. Run web (ReadAsyncIssue), can be under DNX451 or DNXCORE50, no difference
2. Run console app:
   a) when DNX451 is used, ReadAsync returns immediately (read length = 100)
   b) when DNXCORE50 is used, ReadAsync waits for buffer to fill (8192)

I think this is a bug.

[SidharthNabar]

Hi @ppekrol - thanks for reporting this!

We agree that this is a bug and our team will look into it soon. The HttpClient API is implemented via WinHttpHandler in DNXCORE50 but not in DNX 451, which explains why the repro is different between those two platforms.

Thanks
Sid

[SidharthNabar]

@ppekrol - Since we typically track bugs through Microsoft Connect, I went ahead and created one for you: https://connect.microsoft.com/VisualStudio/feedback/details/1392956

You can use that to track the progress on this issue - once we resolve it, the Connect bug will also show as resolved.

Thanks!
Sid.

[ppekrol]

@SidharthNabar - thanks for creating an issue on Connect. Do you know maybe ETA for fix?

With regards,
P.

[SidharthNabar]

@ppekrol - Sure, no problem. We don't have an ETA yet - our team currently has a list of bugs in our backlog and we are continuing to work through them in priority order.

Thanks,
Sid

[ppekrol]

Hey,

confirmed that this is fixed in WinHttpHandler, but the problem still occurs in HttpClientHandler.

Tested on:

• "System.Net.Http": "4.0.1-beta-23502",
• "System.Net.Http.WinHttpHandler": "4.0.0-beta-23502",

[davidsh]

The source code of WinHttpHandler is built into HttpClientHandler. So, if it is fixed in one place, it should be fixed in the other place. Keep in mind that you need to build from sources. I don't think the binary packages have the fix yet. It will be a few days before the binaries pick up the latest source code.

[davidsh]

Also, build 23502 which is the RC1 build candidate DOES NOT have the fix in that branch. This fix is currently only in the [master] branch. We will investigate if we can port this fix to the release/1.0.0-rc1 branch so that the fix will be in the RC1 binaries when RC1 is complete.

[ppekrol]

Thanks @davidsh
I would appreciate if this could be a part of rc1. Please keep me posted.

[davidsh]

@ppekrol This fix has been approved for porting to the release/1.0.0-rc1 branch. So, it should appear within the next few days in the binaries for RC1 candidate.

[ppekrol]

@davidsh Awesome, thanks!