HTTP Request problem


#1

Hi all,

I have an application where I send an http post request, process it in PHP on a LAMP (amazon), then return a string which the client application reads. This works nicely, but some customers complain that they don’t get any response (app says “no internet connection”, which is when timing out, or receiving a null string). I can see on the server though that the request is properly handled and responded upon.

Any ideas what might cause this ? I thought that maybe the lack of some http response header might raise a red flag on some firewall implementations, stopping the response to the client app ?


#2

…sorry, doesn’t ring any bells… Could be some kind of time-out before all the data is received, I guess. Are you getting some customers for whom it never works, or is it intermittent for them?


#3

Some for whom it never works, and I myself cannot reproduce the problem (having the exact same type of internet ADSL connection as one customer). The response time of the server is fast (< 0.5 s), so I don’t really think that timeout is at play, although I cannot rule it out…


#4

Weird… Sorry, my networking expertise isn’t too good, I can’t think of what could be going on.

Are you sure it’s not an error later in your code (e.g. the app gets a valid response, but then mis-parses it and goes down a code-path that makes it look like a http error)? E.g. if it’s XML, maybe it contains errors that are making the XML parser fail?


#5

Unfortunately I’m sure it’s not an error in the code… :frowning:


#6

Could the user have some sort of firewall that’s blocking it?


#7

Yes, that’s my suspicion. However, so far I have not found any info on the net supporting that. The general information is that responses to an outbound (HTTP) request is passed through the firewall untouched.


#8

Maybe your load balancer / some other server on the way is time-outing the request


#9

Hmm… yeah, maybe. But I’ve seen a behavior that might (or might not) shed some light on the issue. I’ve implemented the client appl so that a call to the server, if timed out (using URL::readEntireStreamAsString which has 3 s timeout), will call again (max 4 times) until it gives up or gets an answer.

No answer is interpreted as a timeout.

I’ve seen on the server though that I can get these 4 requests just 1 sec apart, and code-wise, the only way I could get that is if URL::readEntireTextStream returns an empty string almost immediately (i.e. before the 3 sec timeout). And the only way that could happen is if Url::createInputStream returns a nullptr.

What could be the reason for that ? A firewall not allowing the application access to internet ? (this particular problem is on Mac)


#10

I had 2 problems with the URL class, one was the HTTP version that JUCE was using (it was causing errors on some POST requests), the other was a problem with the header User-Agent sent from the APP (it was hard coded to JUCE). That might cause some firewalls to drop the connection cause they will look like some weird HTTP requests (not requests from a web browser)


#11

Ask your users if they are windows 8.

I’ve started noticing the same thing, and I’m starting to think the juce::URL code is broken on windows 8.

Testing, I see it works fine on mac and windows 7, but win8 is giving me an empty string every time.
Specifically, when it gets to createInputStream on windows 8, that doesn’t work (it drops down to a native win class that is problematic for some reason).


#12

Yeah … weird … just checked again.

It works fine on Win 7.
On Win 8, though, createInputStream is always coming back 0.
AFAICT It dies somewhere in the juce_win32_Network.cpp.
WebInputStream::createconnection() creates a valid request but thinks the size is always 0, so closes the connection?

Not sure … but definitely still working on Win 7.

Also - it seems that the readEntireStream() functions on Win 8 still work fine (so it’s just something about creating the stream that is a problem).

Jules - any chance this could get fixed soon? I have a bunch of code that interacts with APIs, and it’s all gonna be crap on Win8.

Plus, I bet it’s a simple fix once you track it down.


#13

I bet it would be. Unfortunately I’m “between PCs” at the moment. Just moved onto a new Mac, and don’t have a Win8 machine until I get a Surface later this month… Can’t you be more specific about where it fails?


#14

Ah, great. You’ve been due for a couple new machines.

I just got a lenovo touchscreen myself and love it (have always been a mac guy, but gotta give it to them on this one).

You’ll find that buttons and sliders and the midikeyboardComponent all need some tweaking for the touch events to work (as you know, touch events trigger down and up immediately, then you need a timer for dragging, and they go back to -1,-1 instead of mouseUp).

I wrote a simple surrogate class last week that intercepts all the mouse events and translates them into mouseDown/Up/Drag events the way Juce expects to see them. I suspect you will have better solutions, but it was quick and easy to just translate them back into the more standard paradigm.

FYI - I’ve been very pleasantly surprised at the speed of the touchEvents (way faster than traditional mouse events). So creating a touch based drum/sample player and turntables has worked out surprisingly well.

Ok - per the discussion at hand, I could dig a little deeper. So far I just stepped through the calls … it definitely came back from the createStream with a 0 (because it thought the amount to read was 0). Why that happened, I’m not sure.

I’ll take another look today and post anything of interest.


#15

ok - got it. It’s only failing on redirects.
That is, when a page has a 302 redirect, Win7 and mac will follow it by default.
Win8 apparently, will not.