Results 1 to 8 of 8

Thread: AsyncRead / openURL returns nothing

  1. #1

    Thread Starter
    Frenzied Member some1uk03's Avatar
    Join Date
    Jun 2006
    Location
    London, UK
    Posts
    1,625

    Question 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.



  2. #2
    Lively Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    119

    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

  3. #3
    PowerPoster
    Join Date
    Feb 2006
    Posts
    23,694

    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.

  4. #4
    Fanatic Member
    Join Date
    Jun 2015
    Posts
    748

    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.

  5. #5
    Lively Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    119

    Re: AsyncRead / openURL returns nothing

    Quote Originally Posted by dz32 View Post
    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.

  6. #6
    Fanatic Member
    Join Date
    Jun 2015
    Posts
    748

    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.

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    23,694

    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.

  8. #8
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    4,122

    Re: AsyncRead / openURL returns nothing

    Quote Originally Posted by dilettante View Post
    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
  •  



Click Here to Expand Forum to Full Width