Open llJochemll opened 5 years ago
Hello @llJochemll
Thanks for your report! Will look very soon.
looks like it is vibe-on-windows specific, as under osx and linux I can't reproduce:
001C0 6F 72 69 7A 61 74 69 6F 6E 20 74 6F 6B 65 6E 20 |orization token |
001D0 69 73 20 70 61 73 73 65 64 2E 5C 72 5C 6E 41 63 |is passed.\r\nAc|
001E0 74 69 76 69 74 79 49 64 3A 20 32 36 36 32 32 63 |tivityId: 26622c|
001F0 39 30 2D 35 32 36 61 2D 34 39 35 34 2D 62 65 65 |90-526a-4954-bee|
00200 61 2D 62 64 61 30 32 63 66 36 61 39 61 64 2C 20 |a-bda02cf6a9ad, |
00210 4D 69 63 72 6F 73 6F 66 74 2E 41 7A 75 72 65 2E |Microsoft.Azure.|
00220 44 6F 63 75 6D 65 6E 74 73 2E 43 6F 6D 6D 6F 6E |Documents.Common|
00230 2F 32 2E 30 2E 30 2E 30 22 7D 0D 0A |/2.0.0.0"}.. |
< HTTP/1.1 401 Unauthorized
< transfer-encoding: chunked
< content-type: application/json
< content-location: https://test.documents.azure.com/
< server: Microsoft-HTTPAPI/2.0
< x-ms-activity-id: 26622c90-526a-4954-beea-bda02cf6a9ad
< strict-transport-security: max-age=31536000
< x-ms-gatewayversion: version=2.0.0.0
< date: Thu, 25 Oct 2018 18:45:34 GMT
< 223 bytes of body received
< 5 bytes of body received
00000 30 0D 0A 0D 0A |0.... |
>> Connect time: 559 ms and 598 μs
>> Request send time: 320 μs
>> Response recv time: 163 ms and 408 μs
This will take more time (I need to set up windows virtual machine).
Hello, @llJochemll
Sorry for long delay, it took some time to set up windows environment and reproduce problem. Working on it.
Hello, @llJochemll
Looks like this is really some problem with vibe.d and ssl - vibe.d do not report availability of last several bytes in some cases when request doc from test.documents.azure.com (50% of tests). My ability to debug vibe.d and ssl under Windows are very limited. I'm afraid I have to put this on hold now.
What do you think?
I was not sure whether the bug originated in vibe or not, but since the exception originated from requests and the build-in vibe http request (http://vibed.org/api/vibe.http.client/requestHTTP) didn't have any problems, I thought I'd post it here first.
I understand that the issue is very specific (specific domain and platform) and it's not a big deal for me anyway since I mostly run my code on linux, but just figured I'd let you know the problem existed.
Thanks for taking the time to look into this!
(Also, if you'd need access to a Windows VM in the future, let me know and I'd probably be able to provision one for a while)
Hello, @llJochemll
Always glad to receive your bug reports.
I was a little busy with my another project 'cachetools'. Now I'm returning back to this problem. Looks like our knowledge on windows sockets are very limited. dub test
also fails on one of the tests.
This is not a Vibe-d problem, it's a Windows socket problem. I get the same error at random times with any http library and even using std.net.curl. I've been struggling with this for a couple of weeks now and still can't find the source of the problem.
Seeing this issue as well. Anyone have a workaround?
std.net.curl works fine for me. Looks like I have to switch over to that until this is fixed.
When performing a request to https://test.documents.azure.com the request fails with "Timeout receiving data". This only happens withe the "vibed" subconfiguration.
Tested multiple other sites (such as httpbin.org), could only reproduce with this one (any on the .documents.azure.com domain). Also tested using the 401 status page from httpbin.org, worked fine too.
Don't know wether it's a vibe-d bug or not, but thought I post it here first since the error is thrown in a file from this library.
Code:
dub.json:
Output (note that the full body is received):
Tested with
dub run --arch=x86_64 --build=plain --compiler=dmd
on a Windows 10 64bit PC.Some comments about the code:
FYI this bug isn't new to 1.0.0, it was also present in the last couple of releases.