Frankly, I have to say that I don't like the tone of this reply ; I'm only
using APIs given to me by Microsoft. The code for the page is pretty
to me by the infrastructure. What is "sloppy" there ? When the problem
it be my fault ???). If Microsoft breaks its own software with every single
new version, that's not my problem, it's Microsoft's problem. If Microsoft
problem. I would appreciate nicer answers than blaming me for using insecure
"David Wang [Msft]" wrote:
> Actually, what I am saying is that:
> 1. ASP.Net is an ISAPI DLL
> 2. I can write an ISAPI DLL that handles big HTTP uploads without problems
> on both IIS5 and IIS6
>
> #2 tells me that IIS6 doesn't have a problem with big HTTP uploads. Other
> ISAPIs may have problems, but that is not an IIS issue -- it is specific to
> that ISAPI. Whether you can solve the issue through configuration of the
> ISAPI -- that is arbitrary behavior as far as IIS is concerned and is
> between you and the ISAPI -- not an IIS problem.
>
> This is why I say this is not something wrong with IIS 6 but rather
> something wrong with either the client app, server app, or their
> configuration.
>
> Also, I suggest that you read the IIS6 Architectural Documentation on how
> IIS6 request processing works.
>
http://www.microsoft.com/resources/documentation/IIS/6/all/techref/en-us/default.mspx >
> I do not know what "timeout" property you are modifying, so I cannot make
> any more suggestions. It may be possible that your upload is not valid or
> somehow forces ASP.Net to inefficiently read it as entity body -- in which
> case you are just depending on arbitrary behavior, which can break on IIS6
> and it would be by-design.
>
> Bottom line: you have to figure out what is wrong before determining whether
> this is your error or not. You cannot assume that "since this code worked on
> IIS5, it must be right". Lots of sloppy stuff worked on IIS5 and is to blame
> for its security issues, and we rewrote and removed all those problems in
> IIS6 -- so it may be that you had some sloppy stuff that may not work
> anymore, but that's the price you must pay for security.
>
> --
> //David
> IIS
>
http://blogs.msdn.com/David.Wang > This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "François Lemaire" <FranoisLemaire@discussions.microsoft.com> wrote in
> message news:C7D3B741-C739-48E3-8340-C97798DF91C6@microsoft.com...
> Thanks for the answer. I've worked on the issue and it seems to work (I
> cross
> fingers, since it doesn't come out every time) when I raise the timeout
> property for ASPNET, though I don't really understand why, since the code I
> wrote to save the file to the disk executes very quickly (at least, quicker
> than the ASPNET timeout...).
>
> Maybe this is an issue of the kernel mode, maybe the timeout for ASPNET
> starts before ASPNET actually starts processing the request (something like
> HTTP.sys detects this is for ASPNET with the HTTP headers, starts ASPNET,
> then waits for the attached files, and when the request is ready to process,
> bang, the ASPNET timeout stops everything). I assure you this is a IIS 6.0
> problem, I never had any problem with the same code on IIS 5.0. Is there a
> way to monitor when the request is transmitted to ASPNET by HTTP.sys ? Maybe
> somebody at Microsoft can check my assumptions ? I'll check network monitor
> anyway.
>
> Regards
>
> François Lemaire
>
> "David Wang [Msft]" wrote:
>
> > It's probably not something within IIS. I have made posts of multiple
> > hundred megabytes to my own ISAPI Upload Acceptor from different machines
> > using default IIS6 configuration without issues.
> >
> > It totally depends on how the client sends data (as soon as possible) and
> > how the server app receives data (in small buffered chunks,
> > asynchronously) -- and depending on how the client/server-app works, you
> may
> > need to configure IIS6 differently. But, as I've already said, the default
> > configuration for IIS6 can handle large POSTs without issues, so you are
> > mostly looking at specific requirements placed by your application
> > framework.
> >
> > I would use Network Monitor to watch network traffic. It will tell you
> > precisely which packets arrived at the server and when -- perf counters
> are
> > not going to tell you exactly what bytes reached where -- which is what
> you
> > are looking for.
> >
> > --
> > //David
> > IIS
> >
http://blogs.msdn.com/David.Wang > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "François Lemaire" <FranoisLemaire@discussions.microsoft.com> wrote in
> > message news:35D0E136-A0F2-48A4-AF37-311685D66397@microsoft.com...
> > Hello,
> >
> > I have recently upgraded a production server with Windows Server 2003,
> thus
> > my IIS 5.0 has become a IIS 6.0 ; one of the .NET web apps on this server
> is
> > using lots of HTTP uploads (multipart encoding), with sometimes very big
> > files (around 50-100Mo). This application works fine on IIS 5.0, but on
> IIS
> > 6.0, when uploading a big file, there are many errors (the user sees an
> > "Action cancelled" page). I've searched every configuration setting
> remotely
> > linked to this and set it to very high levels, but nothing changes. Then I
> > started to look at performance counters, and especially the IIS received
> > octets counter, and it seems like IIS is receiving nothing during a very
> > long
> > period of time, then boom it receives everything in a split second and the
> > response is sent. The bandwidth used during this explosion is way bigger
> > than
> > our internet connection permits, thus i think that somebody is buffering
> the
> > request from IIS.
> >
> > I remembered then that IIS 6.0 closes connections that are inactive for
> too
> > much time, and I will try to change this parameter, but this connection
> > should not be inactive since somebody is sending data. Is this a known bug
> > or
> > limitation ? Is the behaviour I'm experiencing normal or is this a network
> > related issue ? (the server is behind a firewall).
> >
> > Thanks
> >
> >
> >
>
>
