Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » HttpClient Execute vs ExecuteRedirect
HttpClient Execute vs ExecuteRedirect [message #28900] Fri, 24 September 2010 20:36 Go to next message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Hi,

I have a full trial version of my software that calls home as part of its weak protection scheme (clients know). However, one of my customers has some sort of fancy firewall that blocks requests from my app but not the same request when from a browser.

In order to get around this I tried using ExecuteRedirect instead of Execute but that makes my software hang on their system.

What does ExecuteRedirect do please? Also, does that sound right that it just hangs like that? Is there something I can do that will get around this kind of packet filtering or failing that will return and not cause the software to hang please?

For now I am going to just use Execute instead as it appears that if it can't get through then there is no getting through. Perhaps I am using ExecuteRedirect wrong?

BTW I did look for forum posts and documentation on this class but couldn't find any.

Obviously it is pointless trying to submit a test case for this.

Thanks,

Nick

EDIT: what happens when the packets are just swallowed and nothing comes back? Is there a timeout?

[Updated on: Mon, 27 September 2010 18:25]

Report message to a moderator

Re: HttpClient Execute vs ExecuteRedirect [message #29112 is a reply to message #28900] Tue, 05 October 2010 17:37 Go to previous messageGo to next message
rylek is currently offline  rylek
Messages: 79
Registered: November 2005
Member
Hi there!

The main purpose of ExecuteRedirect is to jump over redirection responses. A HTTP server can respond with a result code in the range 300 .. 399 to indicate that the requested resource is available at a different URI. ExecuteRedirect detects these cases and follows the redirection chain to (hopefully) obtain the 'true' final resource. The maximum number of times to hop these redirections is the first parameter in call to ExecuteRedirect and by default is set to the symbolic constant HttpClient::DEFAULT_MAX_REDIRECT ::= 5. Each hop is a separate request and as such it should timeout whenever the server becomes inactive for HttpClient::DEFAULT_TIMEOUT_MSECS ::= 120000 msecs (the default is 2 minutes, see also HttpClient::TimeoutMsecs()).

Note that the timeout check is not entirely reliable: if the server was able to produce, say, 1 byte a minute, the HttpClient would never proclaim it inactive even if dowloading a single web page took three days. On the other hand, you can use the 'progress' parameter in calls to Execute, ExecuteRedirect or HttpClientGet, to supply a custom callback to detect additional reasons for aborting a pending web request (e.g. maximum total duration) and to tell the Http client to stop communicating with the server and return immediately with the appropriate error code.

Regards

Tomas
Re: HttpClient Execute vs ExecuteRedirect [message #29381 is a reply to message #29112] Sun, 17 October 2010 04:43 Go to previous message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Hi Tomas,

Thanks for that. I haven't forgotten about your ray-tracing project - I've just been super busy with other work. I will come back to it soon.

Thanks again,

Nick


Previous Topic: problem with fprintf
Next Topic: Changing mouse shape
Goto Forum:
  


Current Time: Sun Nov 17 01:31:02 CET 2019

Total time taken to generate the page: 0.02089 seconds