WinHTTP and upload progress-VBForums
Results 1 to 20 of 20

Thread: WinHTTP and upload progress

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    WinHTTP and upload progress

    Hello all,

    I need to handle http requests, GET and POST.
    Some are fast, and other involve to download or upload files.
    The site use secure conections (https).
    I would like to have this operations inside one or more class modules, so I prefer not to use a control like Inet or Winsock.

    There are several technologies:
    Wininet API.
    WinHTTP API.
    Msxml2.XMLHTTP object (I don't know much about this one, but seems no to be installed in all systems).
    WinHTTPRequest object.
    And others like the Winsock API or some curl dll.

    I want not to add any dependency file.

    WinHTTPRequest seems fine.
    But there is a problem: I found no way to notify the upload progress.
    The upload is made in a POST call, sending the file as the content body.
    The files can be of any size, up to the gigabytes range.
    I'm planning to upload the files in chunks, may be of 4 MB (is that a good idea anyway, or is it better to make the chunks larger?).
    But I need to show the progress, and 4 MB is still a way too large step to show in the progress.

    I think I will have to go for the WinHTTP API, there is a WinHttpSetStatusCallback that can be set.

    Do you have any suggestion?

    Thanks.

  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    16,573

    Re: WinHTTP and upload progress

    If you look at WINHTTP_STATUS_CALLBACK function pointer I suspect you will find that it won't help either. If it did there would probably be an associated event, since the events just wrap that callback.

    Most HTTP client libraries are not really designed for massive POST requests. That is probably why "request progress" isn't often reported.

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by dilettante View Post
    If you look at WINHTTP_STATUS_CALLBACK function pointer I suspect you will find that it won't help either. If it did there would probably be an associated event, since the events just wrap that callback.

    Most HTTP client libraries are not really designed for massive POST requests. That is probably why "request progress" isn't often reported.
    Ah, OK, thank you.

    So, basically there is no way to show the upload progress, may be with the Winsock API?

    Anyway I'm already thinking in another workaround:
    For files smaller than 4 MB, make the chunks of 250 KB.
    For files between 4 MB and 16 MB, make the chunks of 1 MB.
    For files larger than 16 MB, make the chunks of 4 MB.

    It involves sending many upload requests for each file, even for the small ones, and I'm not sure if it is a good idea...

  4. #4
    Lively Member
    Join Date
    Mar 2017
    Posts
    100

    Re: WinHTTP and upload progress

    Does it really need to be a progress bar? Why not just an animated image like you see on a lot of time consuming operations - the spinning arc you see on Chrome

  5. #5

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by Ordinary Guy View Post
    Does it really need to be a progress bar? Why not just an animated image like you see on a lot of time consuming operations - the spinning arc you see on Chrome
    It's not a progress bar. It's a component and it would be an event with a parameter with the percent done or the number of bytes already uploaded.

    People would want to know whether it will take a minute or an hour.

  6. #6
    PowerPoster
    Join Date
    Feb 2006
    Posts
    16,573

    Re: WinHTTP and upload progress

    Extensions to HTTP such as WebDAV use HTTP PUT to "write" (upload) to the server and these extensions allow data to be uploaded in chunks with a specified byte range.

    So if the server supports WebDAV ranges the client can upload a chunk of data and measure the time it takes to complete. With the chunk size and time it can calculate an estimate to finish uploading, and then chunk the rest of the file piece by piece, updating the estimate/progress as it goes.

    It is easy enough to implement a WebDAV client on top of most common client libraries. You'd just have to fall back to crude HTTP POST requests for servers that don't support WebDAV at all, or whole-file PUT for WebDAV servers not supporting range-PUTs. You'd do an HTTP OPTIONS query to determine server capabilities.

    So for some servers you could do "upload progress" and others not.


    Aside from that you could roll your own HTTP client code on top of TCP. That can be tricky, especially since more and more servers only support HTTPS any more.

  7. #7

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by dilettante View Post
    Extensions to HTTP such as WebDAV use HTTP PUT to "write" (upload) to the server and these extensions allow data to be uploaded in chunks with a specified byte range.

    So if the server supports WebDAV ranges the client can upload a chunk of data and measure the time it takes to complete. With the chunk size and time it can calculate an estimate to finish uploading, and then chunk the rest of the file piece by piece, updating the estimate/progress as it goes.

    It is easy enough to implement a WebDAV client on top of most common client libraries. You'd just have to fall back to crude HTTP POST requests for servers that don't support WebDAV at all, or whole-file PUT for WebDAV servers not supporting range-PUTs. You'd do an HTTP OPTIONS query to determine server capabilities.

    So for some servers you could do "upload progress" and others not.


    Aside from that you could roll your own HTTP client code on top of TCP. That can be tricky, especially since more and more servers only support HTTPS any more.
    No, the server doesn't support PUT, only POST, and it only accepts HTTPS conections.

    But I can send chunks, I have a parameter to set the offset.
    That's my current idea:
    For the first 4 MB, to send chunks of 250 KB.
    From 4 MB to 16 MB, chunks of 1 MB.
    After that, chunks of 4 MB.

    I will check how that performs, and if I see problems I'll have to send only chunks of 4 MB or whatever size I decide at the end, without any good information about the upload progress.

    I can't believe that something that should be simple (in my opinion) is a PITA.

    But it's not the fist time that happen to me that I think that something "is of course a normal operation and there must be a polished mechanism that everybody use" is in fact something very difficult or almost impossible.

    Thanks dilettante, you helped me in confirming (so far) that there is no simple way to overcome this issue.

  8. #8
    PowerPoster
    Join Date
    Feb 2006
    Posts
    16,573

    Re: WinHTTP and upload progress

    Yes, some servers support HTTP PATCH (https://tools.ietf.org/html/rfc5789) while others layer their own similar protocols on top of HTTP.

    Aside from WebDAV you don't see such things much. You might find something in UrlMon but I don't see one:

    HttpSendRequest function

  9. #9

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by dilettante View Post
    Yes, some servers support HTTP PATCH (https://tools.ietf.org/html/rfc5789) while others layer their own similar protocols on top of HTTP. Aside from WebDAV you don't see such things much.
    I wasn't contradicting you.

    Quote Originally Posted by dilettante View Post
    You might find something in UrlMon but I don't see one:

    HttpSendRequest function
    Thanks, I'll take a look.

  10. #10

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    I mean, the server that I'm currently have to work with doesn't offer another way to make uploads than with POST.

    Perhaps in the future I have to make the same for other server that accepts PUT request, but this one doesn't allow this (I think it is for security reasons).

  11. #11
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,946

    Re: WinHTTP and upload progress

    Quote Originally Posted by Eduardo- View Post
    I mean, the server that I'm currently have to work with doesn't offer another way to make uploads than with POST.
    If you have "Scripting-Rights" on the Server in question, you can easily make 3 serverside functions like:
    - ServerOpenStream (e.g. returning a unique TempFileName - after creating that file)
    - ServerAppendBytesToStream (returning the current FileLength after finishing the action, when no Bytes are passed, the routine just returns the lenght)
    - ServerCloseStream (ensuring a final renaming - and returning an SHA-checksum of the serverside-file to compare the result with the clientside)

    I'm using something like that with the WinHttp-5.1-Object and classic *.asp Scripts at the serverside
    (chunksizes are between 64KB and 256KB per Append-Job, depending on the Upload-speed) -
    working very reliable here.

    Olaf

  12. #12

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Thanks Olaf, but I cannot use Scripting on the server.

    I'm already working to test my idea of uploading small chunks at first and bigger after.

    But I am also modifying a lot of things, since all work asynchronously and it's very difficult to handle all that in VB6 whithout the ability of creating new threads.
    I've been reading a bit about Paul Caton approach of creating threads, but as I understood it cannot be done in an OCX, but it must be an ActiveX exe. And ActiveX exe's can't be deployed using SxS (as I think I've read) so they are ruled out.

    So, I'm working with properties like StillExecuting, along with Doevents and setting Timers.
    It's not easy to think about all re-entrancy cases that could happen and to handle all properly.

    I know all this is off-topic, but could you confirm that (or am I wrong)? Thanks.

    PS: I'm talking about many other functions, not only the uploads.
    Last edited by Eduardo-; Apr 14th, 2017 at 09:54 AM.

  13. #13
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,151

    Re: WinHTTP and upload progress

    SxS Multithreading can be done using vbRichClient(or Olaf's DirectCOM?) or Krool's VBMThread10

    http://www.vbforums.com/showthread.p...Multithreader)

  14. #14
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,946

    Re: WinHTTP and upload progress

    Quote Originally Posted by Eduardo- View Post
    Thanks Olaf, but I cannot use Scripting on the server.
    What kind of (Web)Server is it, that prevents you from adjusting it to specific needs, when you have to solve
    the relatively uncommon problem of uploading huge (Gigabyte-range) files per http-POST commands only.

    Is there really no PHP, Python, ASP.NET or anything available at the serverside to you?
    If not, what about changing the Provider?

    Quote Originally Posted by Eduardo- View Post
    I'm already working to test my idea of uploading small chunks at first and bigger after.
    This sounds like the Server-endpoint already supports chunkwise Uploading (appending
    chunks to an existing file) - or does it not?

    And if the chunks have a small enough buffersize (32KB will need about 100-150msec on a connection which has 2MBit/sec Upload-speed),
    you could perform that without having too many "hickups" even in a singlethreaded Application (just checking progress occasionally with a timer).

    Quote Originally Posted by Eduardo- View Post
    But I am also modifying a lot of things, since all work asynchronously and it's very difficult to handle all that in VB6 whithout the ability of creating new threads.
    I've been reading a bit about Paul Caton approach of creating threads, but as I understood it cannot be done in an OCX, but it must be an ActiveX exe. And ActiveX exe's can't be deployed using SxS (as I think I've read) so they are ruled out.

    So, I'm working with properties like StillExecuting, along with Doevents and setting Timers.
    It's not easy to think about all re-entrancy cases that could happen and to handle all properly.
    As for VB6-threading, there's several approaches to that (the RC5 offering only one of them) -
    but in your specific Upload-Scenario I'd consider handling the "huge-files" separately by
    "shelled (GUI-less) VB6-Processes" (to keep it simple), which do nothing else than their FileUpload-Job
    (reporting their Progress into a simple DB-Table, which you can query from anywhere).

    If you have to upload a file with the size of 1GB (on a connection with 2MBit/sec Upload-rate),
    such a process would need to run for about 1.5 to 2hours (if there's multiple processes you start parallel,
    then the time will increase accordingly of course). So, having these (potentially) huge time-intervals
    in mind, separate processes (which are managed from a Client-GUI which might be running - or not),
    seems like a good idea.

    Don't know what you mean with "StillExecuting" - is the scenario DAO- or ADO-based?
    And how is it related to your http-Uploads (are you trying to transfer Recordsets over http)?

    A bit more background-info would be nice to read about.

    Olaf

  15. #15

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    As I understand the code that is intended to be executed in another thread must be -already- compiled in a DLL, or can it be executed in my current OCX project?

    Anyway now I'm thinking that perhaps threading wouldn't help me much to handle re-entrancy, since I still will have to wait with Doevents until the thread finishes and I'm able to return a result synchronously from the calling function (without locking the UI of the client program).

    And it is more or less the same that I'm doing now without threading.

    Most of the functions in my interface to the client program are synchronous, but since they involve a web request I cannot make them without Doevents because even when most of the times the web requests return fast, it's not guaranteed, and there are some of them that can take several seconds because they are more complex and involve several requests to the server and require some processing after.

    So I have to set flags like:

    Code:
    Do While StillExecutingWhatever
        Sleep 1
        Doevents
    Loop
    ' Now I am able to return the result or to go on with another request
    It seems to me now that launching new threads won't help me to avoid that.

    Some other jobs are asynchronous, like the uploads and downloads, and they are notified to the client with events. But I have no problem with these (I think), I suppose that WinHTTP already works creating own threads.

    I cannot test much at this time because I'm currently refactoring all that I have done so far, in order to handle re-entrancy more properly.

  16. #16

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by Schmidt View Post
    What kind of (Web)Server is it, that prevents you from adjusting it to specific needs,
    It's not a server I can have any hand on, it's a web service.

    Quote Originally Posted by Schmidt View Post
    when you have to solve the relatively uncommon problem of uploading huge (Gigabyte-range) files per http-POST commands only.
    Uncommon? May be, but every day less uncommon.
    I said gigabyte range as the larger case, but for more than 10 MB files it's the same situation since I don't know what connection can have the user (how fast).

    I think, due to what I have read, that to use POST is the thend now for security reasons (it is a guess, I don't understand much about it, so don't take it very seriously).

    Quote Originally Posted by Schmidt View Post
    Is there really no PHP, Python, ASP.NET or anything available at the serverside to you?
    No.

    Quote Originally Posted by Schmidt View Post
    If not, what about changing the Provider?
    I have to do this for this provider now. I don't know how the other providers work but must be more or less the same.

    Quote Originally Posted by Schmidt View Post
    This sounds like the Server-endpoint already supports chunkwise Uploading (appending
    chunks to an existing file) - or does it not?
    Yes.

    Quote Originally Posted by Schmidt View Post
    And if the chunks have a small enough buffersize (32KB will need about 100-150msec on a connection which has 2MBit/sec Upload-speed),
    you could perform that without having too many "hickups" even in a singlethreaded Application (just checking progress occasionally with a timer).
    32 KB seem to me too small, that would require many, many web request to be sent for each file. And I think that each web request must have a latency of its own.

    My current idea is to start with 250 KB chunks (or buffersize), and to increase the chunk size when "the uploaded file size" is growing.

    Quote Originally Posted by Schmidt View Post
    As for VB6-threading, there's several approaches to that (the RC5 offering only one of them) -
    but in your specific Upload-Scenario I'd consider handling the "huge-files" separately by
    "shelled (GUI-less) VB6-Processes" (to keep it simple), which do nothing else than their FileUpload-Job
    (reporting their Progress into a simple DB-Table, which you can query from anywhere).

    If you have to upload a file with the size of 1GB (on a connection with 2MBit/sec Upload-rate),
    such a process would need to run for about 1.5 to 2hours (if there's multiple processes you start parallel,
    then the time will increase accordingly of course). So, having these (potentially) huge time-intervals
    in mind, separate processes (which are managed from a Client-GUI which might be running - or not),
    seems like a good idea.
    I think that those must be already handled in another thread by the WinHTTP object...

    Quote Originally Posted by Schmidt View Post
    Don't know what you mean with "StillExecuting" - is the scenario DAO- or ADO-based?
    And how is it related to your http-Uploads (are you trying to transfer Recordsets over http)?

    A bit more background-info would be nice to read about.

    Olaf
    In the message I just posted (before reading this of yours) I explin a bit better (I hope).

    Thanks Olaf.

  17. #17
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,946

    Re: WinHTTP and upload progress

    FWIW, here's an example (using WinHttp5.1 at the clientside and vbRichClient.com as a Test-Endpoint):

    'into a Class, named cHttpChunks
    Code:
    Option Explicit
    
    Event Progress(ByVal CurPos As Currency, ByVal FileSize As Currency)
    
    Const BaseURL As String = "https://vbRichClient.com/asp/"
     
    Function UploadFile(FileName As String, Optional ByVal ChunkSize As Long = 65536) As Boolean
    Dim LocalHash As String, TmpFile As String, Strm As cStream, Pos As Long, B() As Byte
        LocalHash = New_c.FSO.GetFileHash(FileName, CALG_SHA1)
        
      TmpFile = RPC(BaseURL & "StreamOpen.asp")
     
      Set Strm = New_c.FSO.OpenFileStream(FileName, STRM_READ Or STRM_SHARE_DENY_NONE)
      Do Until Pos = Strm.GetSize
         RaiseEvent Progress(Pos, Strm.GetSize)
         Strm.SetPosition Pos
         Strm.ReadToByteArr B, ChunkSize
         Pos = RPC(BaseURL & "StreamAppend.asp?TmpFile=" & TmpFile, B)
      Loop
      RaiseEvent Progress(Pos, Strm.GetSize)
    
      UploadFile = (LocalHash = RPC(BaseURL & "StreamClose.asp?TmpFile=" & TmpFile))
    End Function
    
    Public Function RPC(URL As String, Optional Bytes, Optional ByVal TimeOutSec As Long = 10) As String
      With CreateObject("Winhttp.WinHttpRequest.5.1")
        .Open "POST", URL, 1 'async request-mode
        .SetRequestHeader "Content-Type", "application/octet-stream"
        If IsMissing(Bytes) Then .Send Else .Send Bytes
        If .WaitForResponse(TimeOutSec) Then 'we use the appropriate async-wait-method of WinHttp5.1 (not DoEvents)
          Select Case .Status
            Case 200:  RPC = .ResponseText: If InStr(1, RPC, "Error:", 1) Then Err.Raise vbObjectError, , RPC
            Case Else: Err.Raise vbObjectError, , "Error: http-status=" & .Status & " " & .StatusText
          End Select
        Else
          Err.Raise vbObjectError, , "Error: TimeOut of " & TimeOutSec & " reached."
        End If
      End With
    End Function
    And here the appropriate Code in a little Test-Form:
    Code:
    Option Explicit
    
    Private WithEvents httpChunks As cHttpChunks
    
    Private Sub Form_Click()
      On Error GoTo 1
        Set httpChunks = New cHttpChunks
        New_c.Timing True
        Debug.Print httpChunks.UploadFile("c:\temp\large.zip", 131072), New_c.Timing
    1 If Err Then MsgBox Err.Description
    End Sub
    
    Private Sub httpChunks_Progress(ByVal CurPos As Currency, ByVal FileSize As Currency)
      Debug.Print Format$(CurPos / FileSize, "Percent")
    End Sub
    With an about 4MB TestFile I get the following results at my upload-speed of about 2.5MBit/sec (for different ChunkSizes):
    Code:
    22.687sec '32KB  (about 0.18sec per chunk)
    15.944sec '64KB  (about 0.26sec per chunk)
    15.314sec '128KB (about 0.50sec per chunk)
    15.036sec '256KB (about 0.98sec per chunk)
    So, for the "total-time" of the 4MByte-TestFile-Upload it will not get all that much faster with a buffer-size
    of 256KB - compared to one of 64kByte (the smaller 64kB chunksize updating the progress any 0.25sec or so,
    whilst with 256kB chunksize the time between progress-events was about 1sec.

    Still don't understand, why one would want to upload larger Files (up to 1GB) with a synchronous RPC-call,
    but the example above works this way (as it is currently)...

    HTH

    Olaf

  18. #18

    Thread Starter
    Addicted Member
    Join Date
    Feb 2017
    Posts
    254

    Re: WinHTTP and upload progress

    Quote Originally Posted by Schmidt View Post
    FWIW, here's an example (using WinHttp5.1 at the clientside and vbRichClient.com as a Test-Endpoint):
    Thanks.

    Quote Originally Posted by Schmidt View Post
    Code:
        If .WaitForResponse(TimeOutSec) Then 'we use the appropriate async-wait-method of WinHttp5.1 (not DoEvents)st-Form:
    My question: In practice what difference is supposed to be between the two ways (DoEvents and .WaitForResponse)?

    Quote Originally Posted by Schmidt View Post
    With an about 4MB TestFile I get the following results at my upload-speed of about 2.5MBit/sec (for different ChunkSizes):
    Code:
    22.687sec '32KB  (about 0.18sec per chunk)
    15.944sec '64KB  (about 0.26sec per chunk)
    15.314sec '128KB (about 0.50sec per chunk)
    15.036sec '256KB (about 0.98sec per chunk)
    So, for the "total-time" of the 4MByte-TestFile-Upload it will not get all that much faster with a buffer-size
    of 256KB - compared to one of 64kByte (the smaller 64kB chunksize updating the progress any 0.25sec or so,
    whilst with 256kB chunksize the time between progress-events was about 1sec.
    The progress update every 1 second seems not too bad to me.

    Quote Originally Posted by Schmidt View Post
    Still don't understand, why one would want to upload larger Files (up to 1GB) with a synchronous RPC-call,
    but the example above works this way (as it is currently)...

    HTH

    Olaf
    These upload calls will be asynchronous, but other tasks will be synchronous.
    (I know I mixed things a bit here)

  19. #19
    Lively Member
    Join Date
    Aug 2016
    Posts
    112

    Re: WinHTTP and upload progress

    you can used HttpSendRequestEx InternetWriteFile HttpEndRequest

    upload 10.92%
    ★★★★★★★★★★★★★★★★★★
    upload 21.84%
    ★★★★★★★★★★★★★★★★★★
    upload 32.76%
    ★★★★★★★★★★★★★★★★★★
    upload 43.68%
    ★★★★★★★★★★★★★★★★★★
    upload 54.60%
    ★★★★★★★★★★★★★★★★★★
    upload 65.52%
    ★★★★★★★★★★★★★★★★★★
    upload 76.44%
    ★★★★★★★★★★★★★★★★★★
    upload 87.36%
    ★★★★★★★★★★★★★★★★★★
    upload 98.28%
    ★★★★★★★★★★★★★★★★★★
    upload 100%
    ★★★★★★★★★★★★★★★★★★

    ★★★★★★★★★★★★★★★★★★
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <title>IIS 7.5 Detailed Error - 404.0 - Not Found</title>
    <style type="text/css">
    <!--
    body{margin:0;font-size:.7em;font-family:Verdana,Arial,Helvetica,sans-serif;background:#CBE1EF;}
    code{margin:0;color:#006600;font-size:1.1em;font-weight:bold;}
    .config_source code{font-size:.8em;color:#000000;}
    pre{margin:0;font-size:1.4em;word-wrap:break-word;}
    ul,ol{margin:10px 0 10px 40px;}
    ul.first,ol.first{margin-top:5px;}
    fieldset{padding:0 15px 10px 15px;}
    .summary-container fieldset{padding-bottom:5px;margin-top:4px;}
    legend.no-expand-all{padding:2px 15px 4px 10px;margin:0 0 0 -12px;}
    legend{color:#333333;padding:4px 15px 4px 10px;margin:4px 0 8px -12px;_margin-top:0px;
    border-top:1px solid #EDEDED;border-left:1px solid #EDEDED;border-right:1px solid #969696;
    border-bottom:1px solid #969696;background:#E7ECF0;font-weight:bold;font-size:1em;}
    a:link,a:visited{color:#007EFF;font-weight:bold;}
    a:hover{text-decoration:none;}
    h1{font-size:2.4em;margin:0;color:#FFF;}
    h2{font-size:1.7em;margin:0;color:#CC0000;}
    h3{font-size:1.4em;margin:10px 0 0 0;color:#CC0000;}
    h4{font-size:1.2em;margin:10px 0 5px 0;
    }#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS",Verdana,sans-serif;
    color:#FFF;background-color:#5C87B2;
    }#content{margin:0 0 0 2%;position:relative;}
    .summary-container,.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
    .config_source{background:#fff5c4;}
    .content-container p{margin:0 0 10px 0;
    }#details-left{width:35%;float:left;margin-right:2%;
    }#details-right{width:63%;float:left;overflow:hidden;
    }#server_version{width:96%;_height:1px;min-height:1px;margin:0 0 5px 0;padding:11px 2% 8px 2%;color:#FFFFFF;
    background-color:#5A7FA5;border-bottom:1px solid #C1CFDD;border-top:1px solid #4A6C8E;font-weight:normal;
    font-size:1em;color:#FFF;text-align:right;
    }#server_version p{margin:5px 0;}
    table{margin:4px 0 4px 0;width:100%;border:none;}
    td,th{vertical-align:top;padding:3px 0;text-align:left;font-weight:bold;border:none;}
    th{width:30%;text-align:right;padding-right:2%;font-weight:normal;}
    thead th{background-color:#ebebeb;width:25%;
    }#details-right th{width:20%;}
    table tr.alt td,table tr.alt th{background-color:#ebebeb;}
    .highlight-code{color:#CC0000;font-weight:bold;font-style:italic;}
    .clear{clear:both;}
    .preferred{padding:0 5px 2px 5px;font-weight:normal;background:#006633;color:#FFF;font-size:.8em;}
    -->
    </style>

    </head>
    <body>
    <div id="header"><h1>Server Error in Application "70877835-VBRICHCLIENT.COM"</h1></div>
    <div id="server_version"><p>Internet Information Services 7.5</p></div>
    <div id="content">
    <div class="content-container">
    <fieldset><legend>Error Summary</legend>
    <h2>HTTP Error 404.0 - Not Found</h2>
    <h3>The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.</h3>
    </fieldset>
    </div>
    <div class="content-container">
    <fieldset><legend>Detailed Error Information</legend>
    <div id="details-left">
    <table border="0" cellpadding="0" cellspacing="0">
    <tr class="alt"><th>Module</th><td>IIS Web Core</td></tr>
    <tr><th>Notification</th><td>MapRequestHandler</td></tr>
    <tr class="alt"><th>Handler</th><td>ASPClassic</td></tr>
    <tr><th>Error Code</th><td>0x80070002</td></tr>

    </table>
    </div>
    <div id="details-right">
    <table border="0" cellpadding="0" cellspacing="0">
    <tr class="alt"><th>Requested URL</th><td>http://vbrichclient.com:80/vbRichClient.com/asp/StreamAppend.asp?TmpFile=5B0D.tmp</td></tr>
    <tr><th>Physical Path</th><td>E:\kunden\homepages\44\d438553801\www\vbRichClient.com\vbRichClient.com\asp\StreamAppend.asp</td></tr>
    <tr class="alt"><th>Logon Method</th><td>Anonymous</td></tr>
    <tr><th>Logon User</th><td>Anonymous</td></tr>
    <tr class="alt"><th>Failed Request Tracing Log Directory</th><td><a href="file://faultRequestLogPath">faultRequestLogPath</a></td></tr>
    </table>
    <div class="clear"></div>
    </div>
    </fieldset>
    </div>
    <div class="content-container">
    <fieldset><legend>Most likely causes:</legend>
    <ul> <li>The directory or file specified does not exist on the Web server.</li> <li>The URL contains a typographical error.</li> <li>A custom filter or module, such as URLScan, restricts access to the file.</li> </ul>
    </fieldset>
    </div>
    <div class="content-container">
    <fieldset><legend>Things you can try:</legend>
    <ul> <li>Create the content on the Web server.</li> <li>Review the browser URL.</li> <li>Create a tracing rule to track failed requests for this HTTP status code and see which module is calling SetStatus. For more information about creating a tracing rule for failed requests, click <a href="http://go.microsoft.com/fwlink/?LinkID=66439">here</a%3
    Last edited by xxdoc123; Apr 16th, 2017 at 02:11 AM.

  20. #20
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,946

    Re: WinHTTP and upload progress

    Quote Originally Posted by Eduardo- View Post
    In practice what difference is supposed to be between the two ways (DoEvents and .WaitForResponse)?
    There isn't much of a difference - DoEvents just being the "more generic" solution (+ you need to define "your own loop"),
    whilst WaitForResponse encapsulates a specific Loop already, which internally probably reacts to the Abort-Method of the httpObj.

    Both will keep you App responsive to Win-Messages.

    Quote Originally Posted by Eduardo- View Post
    These upload calls will be asynchronous, but other tasks will be synchronous.
    (I know I mixed things a bit here)
    There are dozens of different ways, to ensure "synchronous-behaviour for asynchronous tasks"
    ('Sleep 1 + DoEvents' being only one of those "non-GUI-blocking Wait-Functions")...

    I'd suggest to open up a new thread though (for the specific problem in question) - when it's more about:
    - how to start threads (which process tasks, which would otherwise block the Main-Application)
    - how to wait for the finishing of these threads within a function that behaves synchronously on the outside

    Olaf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.