Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / April 2006

Tip: Looking for answers? Try searching our database.

Connection is automatically closed after receiving "403" from webs

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
barbutz - 04 Apr 2006 14:38 GMT
Hi,
I have a huge problem with HttpWebRequest/HttpWebResponse.
The problem is when i generate a request using HttpWebRequest to a web
server, when the webserver responds with "403 Forbidden" the connection to
the web server is automatically closed by the .net (i guess by
HttpWebResponse instance)!
I trace the packets and i see that although i get from the web server
"Connection: Keep-Alive" header, the .net framework sends tcp Fin to the
webserver. Of course i forgot to mention that i use http 1.1 and just to make
sure i also set the HttpWebRequest.KeepAlive header to true.
The framework seems to close the "persistent" connection only when it gets
"403", if it gets "404" the connection keeps persistent as it should.
I also debug this situation and saw that the connection immediately close
right after the call (HttpWebResponse)request.GetResponse() is done - long
before the code gets to the response.Close() line.
This behaviour is very critical to my application. I must keep persistent
connection with web server at all time (this is http 1.1 !). The webserver
does not send "Connection: close" header and there is no reason to close the
connection with the web server!! By the way, i did the same with IE browser
and IE acts ok (it does not close the connection).

Please help me with this.
Thanks a lot.
barbutz - 04 Apr 2006 16:20 GMT
Another discovery:
It seems that this problem does not happen in framework 1.1! It happens only
on framework 2.0. Please help me i can go back to 1.1  !

> Hi,
> I have a huge problem with HttpWebRequest/HttpWebResponse.
[quoted text clipped - 19 lines]
> Please help me with this.
> Thanks a lot.
barbutz - 04 Apr 2006 17:50 GMT
If the application is compiled with framework 1.1 (i had to cut many part of
my code for that) there is no problem and when i compile it with 2.0 the
problem appears. I guess it's a problem of framework 2.0 ?
I'll appriciate any help with that since i cannot go back to framework 1.1.

Thx

> Another discovery:
> It seems that this problem does not happen in framework 1.1! It happens only
[quoted text clipped - 23 lines]
> > Please help me with this.
> > Thanks a lot.
barbutz - 05 Apr 2006 08:57 GMT
The problem has another major implication (this bug is serious than i
thought!) if you request the same Forbidden url in a loop, a
System.Net.Sockets.SocketException is thrown continuously!! the socket error
code is 10048 which, from Windows Socket 2 docs, is WSAEADDRINUSE - "Address
already in use". I guess the socket resource is not released correctly !
Please can anyone tell me what's going on. i'm sure the bug is within the
framework but do you know this bug? does it have a fix ???
Please!

> If the application is compiled with framework 1.1 (i had to cut many part of
> my code for that) there is no problem and when i compile it with 2.0 the
[quoted text clipped - 30 lines]
> > > Please help me with this.
> > > Thanks a lot.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.