-
Jun 11th, 2022, 08:52 AM
#1
Thread Starter
Frenzied Member
AsyncRead / openURL returns nothing
So, recently quite a few users have been reporting connection issues with my app. Never had this issue before.
I've tracked it down to being, the URL not returning anything. I do wonder if it has anything to do with the recent Windows Update?
Issue with:
UserControl.AsyncRead URL, vbAsyncTypeByteArray, "ID", vbAsyncReadForceUpdate
Code:
Private Sub UserControl_AsyncReadComplete(AsyncProp As AsyncProperty)
If Not AsyncProp.bytesRead > 0 And Not AsyncProp.bytesRead = AsyncProp.BytesMax Then GoTo errFound
Select Case m_FileType
Case 1 'File
Name AsyncProp.Value As m_SourceDestination
RaiseEvent Completed(AsyncProp.bytesRead, AsyncProp.BytesMax, True, False)
Case 2 'Byte-to-Byte
MsgBox "Bytes: " & AsyncProp.bytesRead '//RETURNS 0 ?????
tempResult = StrConv(AsyncProp.Value, vbUnicode)
End Select
Exit Sub
errFound:
End Sub
Any ideas what could be causing it not to return anything from the web page?
_____________________________________________________________________
----If this post has helped you. Please take time to Rate it.
----If you've solved your problem, then please mark it as RESOLVED from Thread Tools.
-
Jun 12th, 2022, 08:34 AM
#2
Lively Member
Re: AsyncRead / openURL returns nothing
I to noticed this a while back and couldnt figure out why it was happening. The error contained in AsynchProp.Value was "<System Error> The file could not be written to cache"...
Its why I switched over to using WinHttp for all downloads. (you have to reference "Microsoft WinHTTP Services, Version 5.1" in references dialog)
Code:
With New WinHttp.WinHtttpRequest
.Open "GET", Url
.Send
'for byte array
Answer() = .ResponseBody
'for string
Answer = .ResponseText
End With
Last edited by vbLewis; Jun 12th, 2022 at 08:39 AM.
-
Jun 12th, 2022, 11:15 AM
#3
Re: AsyncRead / openURL returns nothing
WinHtttpRequest is a great alternative, except when you are using AsyncRead for its intended purpose of retrieving property values from your server in your OCX hosted in an IE web page. AsyncRead can hit the client machine's cache, radically improving performance. WinHtttp does not use the UrlMon/IE cache, or any cache at all.
Of course hosting controls in HTML pages is pretty obsolete, especially with IE being killed now.
-
Jun 12th, 2022, 11:55 AM
#4
Re: AsyncRead / openURL returns nothing
I just tested one of my apps that uses this. It was returning nothing, but on further investigation the server was returning a 301 moved
message and it just was not following the location header. Once I updated the url to the new one (this time a https url) the async download
worked again.
So seems like the user control download capability is still intact even for https urls. What is the raw server response? maybe watch some packets
in wireshark. verify with another url. Some servers which may demand newer ssl protocols could conceivable no longer work with this trick.
-
Jun 12th, 2022, 02:47 PM
#5
Lively Member
Re: AsyncRead / openURL returns nothing
Originally Posted by dz32
I just tested one of my apps that uses this. It was returning nothing, but on further investigation the server was returning a 301 moved
message and it just was not following the location header. Once I updated the url to the new one (this time a https url) the async download
worked again.
So seems like the user control download capability is still intact even for https urls. What is the raw server response? maybe watch some packets
in wireshark. verify with another url. Some servers which may demand newer ssl protocols could conceivable no longer work with this trick.
It might stop working in 10 days, Microsoft claims it is disabling IE 11 on June 22.
-
Jun 12th, 2022, 05:01 PM
#6
Re: AsyncRead / openURL returns nothing
I debugged it a little bit and it looked like it used the win api directly
Edit: “windows internet api” for the pedantic.
Last edited by dz32; Jun 13th, 2022 at 01:16 AM.
-
Jun 12th, 2022, 08:43 PM
#7
Re: AsyncRead / openURL returns nothing
WinInet/UrlMon are really a layer added on top of Winsock and the rest of Windows, not part of the Windows API itself.
Under the Hood: WinINet
IE itself rides on top of all of that as another layer of software.
Something important to note here is that WinINet is not intended to be used by a server application or Windows service. This is due to the user interaction that is often required by applications that leverage WinINet - such as User Dialogs etc. When writing serviced-based applications, winHTTP.dll should be used instead.
Because of that only attended clients should ever use this stuff. As I said, the AsyncRead mechanism is only meant for OCXs hosted in IE. With IE dying very soon and Windows 9x and NT 4.0 long dead... there isn't any reason ever to use it anymore.
There are rare exceptions (cached GET) and even when IE stops dead this WinInet infrastructure still works. But WinHTTP should be the tool at the top of your tool bag instead. We've had it 20 years or so now.
-
Jun 13th, 2022, 02:10 AM
#8
Re: AsyncRead / openURL returns nothing
Originally Posted by dilettante
But WinHTTP should be the tool at the top of your tool bag instead.
How I so wish this to be true but alas the way WinINet is not recommended for "server application or Windows service" I would not recommend using WinHTTP for "client applications" -- just use WinInet based wrapper (like MSXML2.XMLHTTP) and save yourself the surprises.
The trouble win WinHTTP is that even after 20 years of development it still spins UI thread messages in certain situations. This is like receiving random button clicks in your web-requesting forms but you only notice the disaster happening in error logs as submitted by your end-users from production installations.
Btw, with WinInet cache can be disabled client-side by appending "?ts=" & Now query string if server is not responding with correct cache-control headers (rare but happens).
cheers,
</wqw>
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|