#2245 http::geturl doesn't cleanup from certain errors.

obsolete: 8.5a0
closed-fixed
5
2008-02-28
2003-03-18
No

in http::geturl near the bottom of the proc is this:

# if state(status) is error, it means someone's
already called Finish
# to do the above-described clean up.
if {[string equal $state(status) "error"]} {

should be:

# if state(status) is error, it means someone's
already called Finish
# to do the above-described clean up.
if {![string equal $state(status) "error"]} {

See the new ! in the if expression. Now the code
matches the comment and also works to close the
socket.

Discussion

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2003-07-16

    Logged In: YES
    user_id=72656

    is there an example test to exploit this?

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    no, I don't happen to have one.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    If it's possible to have a connect, then have writes to the
    socket throw an error, the problem will show itself.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    Use httpd on windows for this. You'll get that server socket
    problem where clients are told connect, but the socket isn't
    actually accepted on the server side. Happens at about 16
    requests per second on a 500mHz pIII.

    Use something like this:

    package require http

    proc m_httpCallback {token} {
    global howmuch
    set status [::http::status $token]
    ::http::cleanup $token
    puts "[incr howmuch -1] $status"
    if {$howmuch == 0} {puts Done!}
    }

    proc getem {url count} {
    global howmuch
    set howmuch $count
    for {set i $howmuch} {$i != 0} {incr i -1} {
    ::http::geturl $url -command [list m_httpCallback]
    }
    }

    getem http://localhost 200

     
  • David Gravereaux

    • summary: doesn't cleanup from certain errors. --> http::geturl doesn't cleanup from certain errors.
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2004-05-25

    Logged In: YES
    user_id=72656

    This is from change:
    2000-05-29 Sandeep Tamhankar <sandeep@scriptics.com>

    I'm not sure that the comment is correct though. I don't
    see any negative effect in calling Finish, nor do I see that
    it is called in the above catch already.

     
  • Don Porter

    Don Porter - 2004-05-26

    Logged In: YES
    user_id=80530

    The comment appears correct
    to me. The only code that
    sets state(status) to "error"
    (once the asynchronous
    [geturl] operations are underway)
    is in [Finish]. So at line 501...
    "if state(status) is error, it
    means someone's already called Finish"
    is a true statement.

    I can't say from that what conclusions
    should be drawn. It's not clear to
    me whether [Finish] must be called
    exactly once, no more than once,
    or any number of times per connection.
    See my comments at 513385 about the
    need for a major refactoring of the
    interwoven nest of routines dealing
    with cleanup operations.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    but called less than zero, is much too little.

     
  • Pat Thoyts

    Pat Thoyts - 2008-02-28

    Logged In: YES
    user_id=202636
    Originator: NO

    I've applied this

     
  • Pat Thoyts

    Pat Thoyts - 2008-02-28
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks