Home All Groups Group Topic Archive Search About

Net.WebRequest - Close Connection

Author
28 Aug 2006 10:12 PM
Jack
I have a WebRequest object that I use to log into a site and then post some
XML.  In doing this I set the KeepAlive = true so that it maintains the
connection and does operates undo the initial login.

Is there a way to force this connection to close after I an done with it.
What happens is that I may need to post the XML in several chunks due to
size therefore I cannot set the KeepAlive to False when I post the XML and
the way the code runs I do not know which pass is the last.

What happens is that the first post works fine but subsequent posts time
out, I assume this is due to the connection timing out.

Any ideas, or a better way to do this?

Jack

Author
29 Aug 2006 5:52 AM
Cor Ligthert [MVP]
Jack,

In my idea is this typical a question for the newsgroup

microsoft.public.dotnet.framework.aspnet

Just an advice of course feel free what you do with it.

Cor

Show quoteHide quote
"Jack" <SonomaJack@newsgroups.nospam> schree
f in bericht news:eSIcg8uyGHA.1936@TK2MSFTNGP06.phx.gbl...
>I have a WebRequest object that I use to log into a site and then post some
>XML.  In doing this I set the KeepAlive = true so that it maintains the
>connection and does operates undo the initial login.
>
> Is there a way to force this connection to close after I an done with it.
> What happens is that I may need to post the XML in several chunks due to
> size therefore I cannot set the KeepAlive to False when I post the XML and
> the way the code runs I do not know which pass is the last.
>
> What happens is that the first post works fine but subsequent posts time
> out, I assume this is due to the connection timing out.
>
> Any ideas, or a better way to do this?
>
> Jack
>
Author
29 Aug 2006 10:15 AM
Walter Wang [MSFT]
Hi Jack,

From your post title and first part, your question seems to "how to force
the connection close".

By default, HttpWebRequest.KeepAlive is true. So the connections should be
reused from one request to the next. And I don't think you need to
explicitly close the connection, just dispose the HttpWebRequest object.

Also, note that the server could also be closing the connection after
serving each request. Keep-alive can be set in the http request header, but
server can decide whether or not to reuse the connection.

Reusing connection is to improve performance. I don't think it's required
to maintain the login credential. As long as you are using the same
HttpWebRequest object, the credential should be used in subsequent
requests.

As your last question about "subsequent posts time out", I think this is
probably because the request size limit. If your server is written in
ASP.NET, the default maximum request size is 4MB. You can change this limit
in web.config:

    <system.web>
    <httpRuntime maxRequestLength="10240" /> <!-- change to 10MB -->

http://msdn2.microsoft.com/en-us/library/e1f13641.aspx

    maxRequestLength:

    Specifies the limit for the input stream buffering threshold, in KB.
This limit can be used to prevent denial of service attacks that are
caused, for example, by users posting large files to the server.

Also, you can use WebClient to do the post:
http://msdn2.microsoft.com/en-us/library/tt0f69eh.aspx

If my assumption is not the case, I think a repro project would be very
helpful for us to diagnose the issue quickly.

Sincerely,
Walter Wang (waw***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Author
1 Sep 2006 3:03 PM
Jack
I may be missing something with regard to how the webrequest is used.  What
I did is make the webrequest a global since I go in and out of the sub and
want to maintain the session across these calls.  The first request (a
Post), second (a Get) and third (a Post) work fine, but if  I try to reenter
and execute the same requests again they time out.  I am executing a
"WebRequest1 = Net.WebRequest.Create(strUrl)" on each of the requests since
they go to different URLs, is that correct?  Is there something that I am
just not getting about how this works and how the session is kept active?

Jack


Show quoteHide quote
"Walter Wang [MSFT]" <waw***@online.microsoft.com> wrote in message
news:Vyt8dQ1yGHA.4220@TK2MSFTNGXA01.phx.gbl...
> Hi Jack,
>
> From your post title and first part, your question seems to "how to force
> the connection close".
>
> By default, HttpWebRequest.KeepAlive is true. So the connections should be
> reused from one request to the next. And I don't think you need to
> explicitly close the connection, just dispose the HttpWebRequest object.
>
> Also, note that the server could also be closing the connection after
> serving each request. Keep-alive can be set in the http request header,
> but
> server can decide whether or not to reuse the connection.
>
> Reusing connection is to improve performance. I don't think it's required
> to maintain the login credential. As long as you are using the same
> HttpWebRequest object, the credential should be used in subsequent
> requests.
>
> As your last question about "subsequent posts time out", I think this is
> probably because the request size limit. If your server is written in
> ASP.NET, the default maximum request size is 4MB. You can change this
> limit
> in web.config:
>
>    <system.web>
>    <httpRuntime maxRequestLength="10240" /> <!-- change to 10MB -->
>
> http://msdn2.microsoft.com/en-us/library/e1f13641.aspx
>
>    maxRequestLength:
>
>    Specifies the limit for the input stream buffering threshold, in KB.
> This limit can be used to prevent denial of service attacks that are
> caused, for example, by users posting large files to the server.
>
> Also, you can use WebClient to do the post:
> http://msdn2.microsoft.com/en-us/library/tt0f69eh.aspx
>
> If my assumption is not the case, I think a repro project would be very
> helpful for us to diagnose the issue quickly.
>
> Sincerely,
> Walter Wang (waw***@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
Author
4 Sep 2006 7:16 AM
Walter Wang [MSFT]
Hi Jack,

Although you make the webrequest a global variable, but you are recreating
it on each request by Net.WebRequest.Create(strUrl).

To maintain the session after you first logged on, you need to use a
CookieContainer to store the cookies you obtained after the first request
to logon. For more information, see
http://blogs.vbcity.com/drydo/archive/2005/09/27/5556.aspx

Hope this helps. Please feel free to post here if anything is unclear.

Regards,
Walter Wang (waw***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Author
5 Sep 2006 3:50 PM
Jack
I looked at the code in the link you attached and that is basically what I
am doing for my logon and response.  How would I compose my next post
request?  Do I use .create(url) and then set .cookiecontainer = CookieC?

Also, is there a good resource on coding this?  I have purchased "MS Visual
Basic 2005: The Language", "101 Visual Basic .NET Applications", "Visual
Studio Tools for Office" and A! Apress's "Programming the Web with Visual
Basic .NET"; none of which really seem to take about using the WebRequest
object to access secure web resources inside a VB.NET Windows Application.

Jack

Show quoteHide quote
"Walter Wang [MSFT]" <waw***@online.microsoft.com> wrote in message
news:cK5LCI$zGHA.4464@TK2MSFTNGXA01.phx.gbl...
> Hi Jack,
>
> Although you make the webrequest a global variable, but you are recreating
> it on each request by Net.WebRequest.Create(strUrl).
>
> To maintain the session after you first logged on, you need to use a
> CookieContainer to store the cookies you obtained after the first request
> to logon. For more information, see
> http://blogs.vbcity.com/drydo/archive/2005/09/27/5556.aspx
>
> Hope this helps. Please feel free to post here if anything is unclear.
>
> Regards,
> Walter Wang (waw***@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
>
> ==================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
Author
6 Sep 2006 2:02 AM
Walter Wang [MSFT]
Hi Jack,

Thank you for your update. You are right that you need to pass the
CookieContainer object to your second request.

When using System.Net or Web Services, you might want to receive or send
cookies, perhaps for session state maintenance or in some rate situations
for proxy authentication. CookieContainer is designed to be a store of all
the cookies for one or more requests. To that extent, the CookieContainer
is designed to be a Hashtable of "domain - CookieCollection" pairs.

For more information, please refer to following article:

#Cookies, Cookie Collection and CookieContainer
http://blogs.msdn.com/dgorti/archive/2005/08/16/452347.aspx

And here're some other KB articles related to CookieContainer you may find
useful:

#How to authenticate the Inbox in Exchange Server 2003 with forms-based
authentication enabled by using Visual Basic.NET
http://support.microsoft.com/kb/891748/

#HOW TO: Use CookieContainer to Maintain a State in Web Services Using
Visual Basic.NET
http://support.microsoft.com/kb/820528/

Hope this helps. Please feel free to post here if anything is unclear.


Regards,
Walter Wang (waw***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.