Products

Price/Order

Support

Partners

Testimonials

Test Results

About us

Contact
 unstable TRtcHttpClient when using WinHTTP
Bottom
 
Total posts: 8
 Author unstable TRtcHttpClient when using WinHTTP
Kevin Lu

27.05.2008 22:52:13
Registered user
After I upgrade RTC SDK from 2.78 to 2.82,
I found it's very unstable when using WinHttp.

sometimes the content-length is 0,
sometimes the content is incompleted,
sometimes I got response abort.

But if I set UseWinHttp to false, everything is OK.
Danijel Tkalcec [RTC]

27.05.2008 23:40:44
Registered user
Hi Kevin,

1) Have you also been using WinHTTP in RTC SDK version 2.78? If you revert to RTC SDK 2.78 now and recompile your project, do your problems disapear? (RTC SDK 2.78 should still be available for download from SourceForge)

2) Can you please give me an example for each of your above mentioned problems with WinHTTP?

3) When you set useWinHTTP to FALSE, do you set useProxy to TRUE or are any Proxy parameters set in the UserLogin property, which would indicate that WinInet? Or do you know that WinSock is used because you aren't behind a proxy?

4) Can you reproduce your problems using some publicly available Web Server and the standard File_Client demo, or send me a small example project which would demnstrate your problems? If there is a real problem, I need more information to debug it. With the information you have provided above, I really can't do much than make a wild guess.

One of the things that is different in the latest WinHTTP connection provider is that the auto-redirect feature is now disabled to make the functionality of WinHTTP connection provider more similar to that of WinSock.

This means that requests which you would send to an URL that tries to redirect the client to another URL will NOT automatically be processed anymore. Instead, you will get the response from the Server with zero content length and "Response.StatusCode" set to 301 or 302. There are also other status codes which you will now get when useWinHTTP set to TRUE which you would not have seen in prior implementations because they were handled incorrectly (204, 304 and 100..199).

There were no other changes in the WinHTTP connection provider between versions 2.78 and 2.82, so the functionality of your RTC Clients should not have changed unless they have been depending on the WinHTTP auto-redirect feature.

Best Regards,
Danijel Tkalcec
Kevin Lu

28.05.2008 00:27:11
Registered user
1. I use WinHTTP in v 2.78

2. I don't really known what example you want.
I don't known how to reproduce it. they occured with the same url , randomly.

I already handle the relocate myself, I don't think it's the problem.
ps: when the content is empty, the response header's status code is 200,
and content-length is 0. but it should not be 0.

3. I did not use any proxy settings.
Danijel Tkalcec [RTC]

28.05.2008 00:34:33
Registered user
1) Is this happening with a WebServer available over the Internet, or is this with a Server inside your LAN? If it is a WebServer available over the Internet, can I have the URL which generates random errors, please? You can send me the URL by E-Mail if you dont want to post it here in a public forum.

2) If you say the problems have started with RTC SDK 2.82, can you please revert to RTC SDK 2.78 and see if the old version works without these problems?

3) Is your RTC Client talking to a third-party WebServer, or to a Server written with the RTC SDK?

Without additional information, I really have nothing to test your scenario and there have been no other changes in the WinHTTP connection provider between versions 2.78 and 2.82 than the ones I have explained above. And all the changes made to the WinHTTP connection provider should NOT affect its behavior as you have described.

Best Regards,
Danijel Tkalcec
Kevin Lu

28.05.2008 01:26:18
Registered user
1. it's the webserver over the internet. I've send you the email.

2. "content-length is 0" problem didn't happened in the v 2.78.   

"content is incompleted" happened in both v2.78 and v2.82.
after I add Value['Accept-Encoding']:='gzip,deflate';  to the request header.


3. third-party WebServer
Danijel Tkalcec [RTC]

28.05.2008 02:02:05
Registered user
Thank you for the E-Mail.

According to the information you have sent me by E-Mail, the problems you are now facing are related to the fact that WinHTTP does NOT handle relocation automatically anymore, so you are now receiving relocate requests in your code which were handled by WinHTTP before.

If the Server you are working with is sending you "silent" relocate requests (requests to relocate only by setting the "Location" header but not using 301 or 302 status code), you will need to check the Response.Value['Location'] to see if the response you have received is asking you to relocate. This is NEW in RTC SDK 2.82 because relocate requests are no longer processed automatically when using WinHTTP.

As for the Accept-Encoding header you have been sending to the Server, since RTC Client does not implement GZIP nor DEFLATE, I do not see how that could work unless you implement your own GZIP/DEFLATE mechanism.

Best Regards,
Danijel Tkalcec
Kevin Lu

28.05.2008 03:21:42
Registered user
I implement my own GZIP/DEFLATE mechanism.
Danijel Tkalcec [RTC]

28.05.2008 04:01:54
Registered user
Thank you for your further E-Mails and a point in the right direction, which has helped me to find out where the real source of your problems is.

A new RTC SDK update (v2.83) is now ready for download from the "RTC Download Area". Should you have any other problems with the RTC SDK (or if this update should not fix your problem), please let me know.

Best Regards,
Danijel Tkalcec