Re: Accessing Request.InputStream / Request.BinaryRead *as the request is occuring*: How???

Discussion in 'ASP .Net' started by Brian Birtle, Oct 16, 2003.

  1. Brian Birtle

    Brian Birtle Guest

    John,
    Thanks again for your post.

    I saw the IHttpAsyncHandler class back when I was researching the
    problem and thought "Eureka!" But when I looked into it it seems like
    the purpose is actually to handle certain cases where the HTTP
    *response* (not request) should be made based on external events -
    like bytes read from a slow data stream which you've connected to from
    the server... short answer is it doesn't seem to do what I need.

    Unforunately I've been too busy to build a test case, but I suspect
    since it's also based on the HttpContext/HttpRequest framework the
    behavior will be the same as an HttpHandler, which has the same
    thread-blocking problem.

    Any other ideas?

    - Brian

    "John Saunders" <john.saunders at surfcontrol.com> wrote in message news:<#>...
    > "Brian Birtle" <> wrote in message
    > news:...
    > > John, Thanks for responding.
    > >
    > > I should clarify that my question is not about creating a progress
    > > meter per se as I have already successfully created one using ASP
    > > classic. My question is, generally speaking, why do
    > > Request.BinaryRead, Request.InputStream, and Request.Filter thread
    > > block and is there a workaround?

    >
    > Yes. The workaround to synchronous behavior is to use an asynchronous
    > handler. See IHttpAsyncHandler in the documentation.
    >
    > Even if you can find a way to not block until the entire request has been
    > read, I hope you realize that there is still no correspondence between the
    > time you receive a byte and the time the client sent it, except that you can
    > be certain the byte was sent before it was received. As an example, you
    > might read the first ten bytes very soon after the client sent them, but the
    > next ten bytes might be received after the client has finished sending the
    > entire request. If this is not acceptible, you should not be using HTTP.
    >
    > >
    > > Here is some example code to show what I'm talking about (put in your
    > > global.asax or class that derives from HttpApplication):
    > >
    > > ... On_BeginRequest(...)
    > > {
    > > ////This line gets executed right when the HTTP connection is
    > > // opened (before even any of the HTTP request is read):
    > > Application["UploadState"] = "started";
    > > ...

    >
    > I hope you meant Session and not Application, unless you can ensure that
    > there will never be more than one request at a time.
    Brian Birtle, Oct 16, 2003
    #1
    1. Advertising

  2. "Brian Birtle" <> wrote in message
    news:...
    > John,
    > Thanks again for your post.
    >
    > I saw the IHttpAsyncHandler class back when I was researching the
    > problem and thought "Eureka!" But when I looked into it it seems like
    > the purpose is actually to handle certain cases where the HTTP
    > *response* (not request) should be made based on external events -
    > like bytes read from a slow data stream which you've connected to from
    > the server... short answer is it doesn't seem to do what I need.
    >
    > Unforunately I've been too busy to build a test case, but I suspect
    > since it's also based on the HttpContext/HttpRequest framework the
    > behavior will be the same as an HttpHandler, which has the same
    > thread-blocking problem.
    >
    > Any other ideas?


    Well, I know it's not _just_ a matter of the response being asynchronous.
    The BeginProcessRequest method can initiate a chain of asynchronous events,
    so at least the processing of the request can be done in parallel.

    The question will be: is it the case that BeginProcessRequest is only called
    after the entire request has been read in?
    --
    John Saunders
    Internet Engineer



    > "John Saunders" <john.saunders at surfcontrol.com> wrote in message

    news:<#>...
    > > "Brian Birtle" <> wrote in message
    > > news:...
    > > > John, Thanks for responding.
    > > >
    > > > I should clarify that my question is not about creating a progress
    > > > meter per se as I have already successfully created one using ASP
    > > > classic. My question is, generally speaking, why do
    > > > Request.BinaryRead, Request.InputStream, and Request.Filter thread
    > > > block and is there a workaround?

    > >
    > > Yes. The workaround to synchronous behavior is to use an asynchronous
    > > handler. See IHttpAsyncHandler in the documentation.
    > >
    > > Even if you can find a way to not block until the entire request has

    been
    > > read, I hope you realize that there is still no correspondence between

    the
    > > time you receive a byte and the time the client sent it, except that you

    can
    > > be certain the byte was sent before it was received. As an example, you
    > > might read the first ten bytes very soon after the client sent them, but

    the
    > > next ten bytes might be received after the client has finished sending

    the
    > > entire request. If this is not acceptible, you should not be using HTTP.
    > >
    > > >
    > > > Here is some example code to show what I'm talking about (put in your
    > > > global.asax or class that derives from HttpApplication):
    > > >
    > > > ... On_BeginRequest(...)
    > > > {
    > > > ////This line gets executed right when the HTTP connection is
    > > > // opened (before even any of the HTTP request is read):
    > > > Application["UploadState"] = "started";
    > > > ...

    > >
    > > I hope you meant Session and not Application, unless you can ensure that
    > > there will never be more than one request at a time.
    John Saunders, Oct 16, 2003
    #2
    1. Advertising

  3. "John Saunders" <john.saunders at surfcontrol.com> wrote in message
    news:%23OdLK2%...
    > "Brian Birtle" <> wrote in message
    > news:...
    > > John,
    > > Thanks again for your post.
    > >
    > > I saw the IHttpAsyncHandler class back when I was researching the
    > > problem and thought "Eureka!" But when I looked into it it seems like
    > > the purpose is actually to handle certain cases where the HTTP
    > > *response* (not request) should be made based on external events -
    > > like bytes read from a slow data stream which you've connected to from
    > > the server... short answer is it doesn't seem to do what I need.
    > >
    > > Unforunately I've been too busy to build a test case, but I suspect
    > > since it's also based on the HttpContext/HttpRequest framework the
    > > behavior will be the same as an HttpHandler, which has the same
    > > thread-blocking problem.
    > >
    > > Any other ideas?

    >
    > Well, I know it's not _just_ a matter of the response being asynchronous.
    > The BeginProcessRequest method can initiate a chain of asynchronous

    events,
    > so at least the processing of the request can be done in parallel.
    >
    > The question will be: is it the case that BeginProcessRequest is only

    called
    > after the entire request has been read in?


    P.S. So you should go try the above and get back to us.

    If BeginProcessRequest doesn't happen until the entire request has been read
    in, then you're SOL as far as standard ASP.NET. This would leave you needing
    to implement your own host for ASP.NET. See the Cassini web server at
    http://asp.net for an example of this.
    --
    John Saunders
    Internet Engineer
    John Saunders, Oct 16, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lau Lei Cheong

    Question about using Request.BinaryRead()

    Lau Lei Cheong, Aug 23, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    636
    bruce barker
    Aug 23, 2004
  2. R
    Replies:
    5
    Views:
    2,113
    Kevin McMurtrie
    Mar 13, 2005
  3. Nikhil
    Replies:
    1
    Views:
    177
    GVaught
    Sep 11, 2003
  4. Roberto
    Replies:
    1
    Views:
    146
  5. Replies:
    0
    Views:
    338
Loading...

Share This Page