Response.ContentType = "text/plain"
Response.AddHeader "Content-Disposition", "attachment;filename=""file.txt"""
Response.AddHeader "Content-Length", "3100"
Response.BinaryWrite FileBody
But on IIS7, it does not. Via elimination, I found the culprit to be the
line
Response.AddHeader "Content-Length", "3100"
Remove it, and it works fine again (although there is no file size
information, of course.)
You can also disable both Enable Buffering and Enable Chunked Encoding under
ASP settings, and it will work again. Great, ain't it? What gives! How long
is M$ going to test our patience with tricks like that?????
-- Abe
http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.4
Note the 3rd bullet point - you cannot use Content-Length with
Transfer-Encoding (which is used for chunked encoding).
http://msdn.microsoft.com/en-us/library/aa347544(VS.90).aspx
EnableChunkedEncoding is True by default in IIS7.
I can see how this could be annoying - I have a few applications which set
Content-Length too. With this having been changed from IIS 6 to IIS 7
Microsoft should have put in provision handling for applications setting
Content-Length - either disable Chunked Encoding for that response, or
remove the Content-Length header automatically.
I've never used the Content-Length header with buffering enabled in IIS 6 or
earlier - by having buffering enabled IIS will automatically add the correct
Content-Length header. I've only ever use Content-Length with buffering
disabled and flushing the buffer in a loop using BinaryWrite in small
pieces, as it's not possible for IIS to determine the amount of data being
sent in total in this situation.
If you check the response with Fiddler2 with buffering enabled, is IIS
adding an additional Content-Length header itself?
--
Dan
Odd, according to the following article this should potentially affect IIS6
too as it's enabled by default
However, it will only be enabled for sites that are not using buffering -
and as that is set on by default too. I've just tested it by disabling
buffering on one of my IIS6 sites and with Fiddler2 I can see that it starts
using chunked encoding for the responses.
The defaults for IIS 7 don't appear to have changed, *but* you will get
chunked encoding if you have enabled dynamic compression. It appears that
the default for the doDynamicCompression attribute was changed in IIS 7.5
from false to true.
http://www.iis.net/ConfigReference/system.webServer/urlCompression
note that under the Compatibility section this page states that the default
value was changed from false to true as of IIS 7.5, yet under the
Configuration section further down the page states that the default value
was true in IIS 7 and false in IIS 7.5, however the text above that
statement is the reverse.
Are you definitely running IIS 7? Or are you actually running IIS 7.5?
--
Dan
Response.ContentType = "text/plain"
Response.AddHeader "Content-Disposition", "attachment;filename=""file.txt"""
Response.AddHeader "Content-Length", "3100"
Response.Flush()
Response.BinaryWrite FileBody
No other changes are required. Buffering does not need to be disabled.
>> On Thursday, July 22, 2010 4:07 AM Dan wrote:
>> http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.4
>>
>> Note the 3rd bullet point - you cannot use Content-Length with
>> Transfer-Encoding (which is used for chunked encoding).
>>
>> http://msdn.microsoft.com/en-us/library/aa347544(VS.90).aspx
>>
>> EnableChunkedEncoding is True by default in IIS7.
>>
>> I can see how this could be annoying - I have a few applications which set
>> Content-Length too. With this having been changed from IIS 6 to IIS 7
>> Microsoft should have put in provision handling for applications setting
>> Content-Length - either disable Chunked Encoding for that response, or
>> remove the Content-Length header automatically.
>>
>> I have never used the Content-Length header with buffering enabled in IIS 6 or
>> earlier - by having buffering enabled IIS will automatically add the correct
>> Content-Length header. I have only ever use Content-Length with buffering
>> disabled and flushing the buffer in a loop using BinaryWrite in small
>> pieces, as it is not possible for IIS to determine the amount of data being
>> sent in total in this situation.
>>
>> If you check the response with Fiddler2 with buffering enabled, is IIS
>> adding an additional Content-Length header itself?
>>
>> --
>> Dan
>>> On Thursday, July 22, 2010 4:26 AM Dan wrote:
>>> Odd, according to the following article this should potentially affect IIS6
>>> too as it is enabled by default
>>>
>>> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/c9b722e8-189f-4bfe-8716-70bf8d2271df.mspx?mfr=true
>>>
>>> However, it will only be enabled for sites that are not using buffering -
>>> and as that is set on by default too. I have just tested it by disabling
>>> buffering on one of my IIS6 sites and with Fiddler2 I can see that it starts
>>> using chunked encoding for the responses.
>>>
>>> The defaults for IIS 7 do not appear to have changed, *but* you will get
>>> chunked encoding if you have enabled dynamic compression. It appears that
>>> the default for the doDynamicCompression attribute was changed in IIS 7.5
>>> from false to true.
>>>
>>> http://www.iis.net/ConfigReference/system.webServer/urlCompression
>>>
>>> note that under the Compatibility section this page states that the default
>>> value was changed from false to true as of IIS 7.5, yet under the
>>> Configuration section further down the page states that the default value
>>> was true in IIS 7 and false in IIS 7.5, however the text above that
>>> statement is the reverse.
>>>
>>> Are you definitely running IIS 7? Or are you actually running IIS 7.5?
>>>
>>> --
>>> Dan
>>> Submitted via EggHeadCafe
>>> Serializing Excel data for input to any Google visualization
>>> http://www.eggheadcafe.com/tutorials/aspnet/571d84dc-9fcf-44de-b2ad-005c12372ab3/serializing-excel-data-for-input-to-any-google-visualization.aspx