-
Notifications
You must be signed in to change notification settings - Fork 183
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
Moving from Requests.jl to HTTP.jl #58
Comments
You'll have to give a little information as to what seems to be wrong; all I see are two GET requests that both returned 200s. One thing in particular that can be helpful is to run |
Oh, sorry. The Requests version of |
I'm more than happy to help debug what's going on; like I mentioned, posting the results of |
Cool, thanks. The code (using Requests) is all here. It controls my lights — it would be cool if you could access it from where you are, but perhaps a bit worrying as well... :) From Requests I get:
And from HTTP I get:
|
@cormullion if you could get a packet trace using something like Wireshark, I think that might be helpful here so we can compare exactly what goes back and forth. |
I eventually got Wireshark working, but didn't really know what to look for. Will keep at it. It seems to me that
|
Is it possible for you to expose this web service to the outside world so that we can hit it as well? |
Regarding Wireshark, if you can just record on your machine while you run those commands in Julia, then save a |
Here's a pcap file made in Wireshark of the following two Julia commands:
The first one appears to work, the second one only returns some of the information. |
@quinnj I don't know if you're very familiar with Wireshark, but there's a few interesting nuggets here. First off, the HTTP request being made by both libraries looks to me to be essentially identical. Sure, there are different I don't know why this would happen, but it definitely looks to me like something is calling |
bump |
I haven't tried it again, but I didn't know whether it was just a Philips Hue interface quirk or a strange entanglement with Http.jl. Will look again next week. |
@staticfloat, a big thanks for looking into this. Definitely weird that the premature Also, would you be willing to share how you were able to reproduce? I'd like to be able to take a look myself locally. |
@quinnj I can try running my original code against the latest (using UpdateOn HTTP master and Julia v0.6, this time the same
|
Unrelated problem suggests that I'm better off with Requests at the moment. Closing for now, will revisit later this year. |
@samoconnor I thought perhaps it was just the Hue light interface causing problems. If it's a more general issue, perhaps it's another datapoint. |
Hi @cormullion, I think its very valuable to have issue reports relating to IOT devices. Testing with the big 3 desktop/server OSs is good, but the variety of different TPC/IP and HTTP implementations that is out there on embedded devices is huge. Embedded devices tend to have different timing behaviour and different message fragmentation behaviour due to slow micros and small RAM size. It's important to handle them gracefully even if they are not all HTTP compliant. (BTW: I have hue lights here, so I could test stuff if needed...) |
@cormullion Is it making the request that was hanging, or just printing the response? A few days ago I encountered hanging when printing the The issue with subsequent requests getting truncated, apparently due to an early close call, still persists for me. Maybe we need to pitch in to get quinnj a Hue setup :) |
Has anyone been able to try this/seen any issues on latest HTTP master? It'd be great if we had a repro here to dig into. |
Yes I find the same problems. For example, each time I query the box I get different amounts of the status info returned.
|
I just merged a fix for an issue that may be related to this one; in case anyone is willing to try to reproduce this again on current master. |
I'm not seeing any improvement on my particular problem box... :( Sorry...!
|
FWIW, I've just repeated this text against my own Phillips Hue bridge with the same result (a different random amount of data is returned each time). |
|
|
…s that don't provide a content-length and we need to rely on the connection being closed to detect eof
@samoconnor thank you thank you thank you for posting the debug output! I think I have a better idea of what's going on here. For cases where the server doesn't send an explicit If someone could pull #103 and try it out, I'd really appreciate it. Unfortunately |
Looks stable now:
But, there is a 4 x slowdown compared to Requests (I assume this is all compilation delay?)
|
Excellent news! I'm going to merge that PR then. Yes, there's still a bit of a delay in terms of package loading/precompilation, but it's now weighted more heavily to the upfront package loading instead of initial request call (which should benefit applications which would prefer to have a slower upfront load time). There are also open issues that have been slotted for resolution by 1.0, so I'm optimistic that it will all come out nice in time. |
Just wondering whether it's easy (or advised) to move from using Requests.jl to HTTP.jl. I thought it might be possible to simply swap, but now I'm not so sure:
Here's Requests, followed by HTTP:
The text was updated successfully, but these errors were encountered: