ASP.NET File Server Issue

[hb]

I am having trouble with creating a document server from a database using
asp.net.
It works on the development machine (win2k, iis5.0), but fails on the
production server (win2003, iis6.0).
The production server is not failing in all circumstances, however. The
behavior has the following characteristics:

1) serving of gif and jpg files work fine on both machines
2) serving of pdf files works on:
a) the development server through http - always (client on dev server or
another machine)
b) the production server when sent via http
c) the production server through https when the client is also run on
the production server
and fails on:
a) the production server when sent via https

In the failing cases, the client gets a dialog box with the following
message:
Acrobat could not open 'xxx.fdf' because it is either
not a supported file type or because the file has been
corrupted (for example it was sent as an e-mail
attachment and wasn't properly decoded).

I find it strange that pdf says 'xxx.fdf' rather than 'xxx.pdf'. That is
not a typo. It is not an error in the document server either since the code
is the same when it works and when it doesn't work.

After reading some of the comments on the forum, from people with similar
questions, I tried increasing the expiration from "immediate" to 5 minutes.
I've also increased the page timeout setting to 90 seconds though this
document is small enough to be sent in well under 10 seconds.

The pertinent code is as follows:

Response.Clear();
Response.ContentType = "application/pdf"; // note this
is image/gif or image/jpg for the other formats
Response.AppendHeader("Content-Length", ""+docSize);
Response.AppendHeader("Content-Disposition", "inline;
filename="+docName); // note, tried it with/without "inline; " inculded
it didn't have an observable effect.
Response.BinaryWrite(doc);
Response.End();

All suggestions welcome.

hb

[hb]

New info, the server works, but apparently only from machines without adobe
acrobat professional (the acrobat creater, not just the reader version)
installed.
Is there an issue with file associations or something like that? Why would
it on
machines with the adobe professional through http, but not https?

I am having trouble with creating a document server from a database using
asp.net.
It works on the development machine (win2k, iis5.0), but fails on the
production server (win2003, iis6.0).
The production server is not failing in all circumstances, however. The
behavior has the following characteristics:

1) serving of gif and jpg files work fine on both machines
2) serving of pdf files works on:
a) the development server through http - always (client on dev server or another machine)
b) the production server when sent via http
c) the production server through https when the client is also run on
the production server
and fails on:
a) the production server when sent via https

In the failing cases, the client gets a dialog box with the following
message:
Acrobat could not open 'xxx.fdf' because it is either
not a supported file type or because the file has been
corrupted (for example it was sent as an e-mail
attachment and wasn't properly decoded).

I find it strange that pdf says 'xxx.fdf' rather than 'xxx.pdf'. That is
not a typo. It is not an error in the document server either since the code is the same when it works and when it doesn't work.

After reading some of the comments on the forum, from people with similar
questions, I tried increasing the expiration from "immediate" to 5 minutes. I've also increased the page timeout setting to 90 seconds though this
document is small enough to be sent in well under 10 seconds.

The pertinent code is as follows:

Response.Clear();
Response.ContentType = "application/pdf"; // note this is image/gif or image/jpg for the other formats
Response.AppendHeader("Content-Length", ""+docSize);
Response.AppendHeader("Content-Disposition", "inline;
filename="+docName); // note, tried it with/without "inline; " inculded
it didn't have an observable effect.
Response.BinaryWrite(doc);
Response.End();

All suggestions welcome.

hb

[Alexander]

hb,

how large is that PDF file? If it is a very large file (> 100 MB), try this
KB article:
http://support.microsoft.com/default.aspx?kbid=823409

It introduces a new method, Response.TransmitFile (which is included in the
hotfix mentioned, but is also part of the .NET Framework 1.1 Service Pack 1).
That method solved all my downloading problems.
On the other hand, the HTTPS part sounds more suspicious. Are your
certificates installed correctly?

Al

[hb]

Thanks al,

In the current case, this is probably not the issue since the
file is only 130KB (tiny) my server is slow (128 or 256 dsl).
Though i will switch to this because future files may be larger
(hopefully not before my connection is upgraded;).

The certificates appear to be in place (clients show the lock
and the certificates can be reviewed on the client) and the
general functionality of the web site appears solid (6 months
in production).

Any more suggestions? Anyone?
"Alexander" <Al*******@discussions.microsoft.com> wrote in message
news:E8**********************************@microsof t.com...

hb,

how large is that PDF file? If it is a very large file (> 100 MB), try this KB article:
http://support.microsoft.com/default.aspx?kbid=823409

It introduces a new method, Response.TransmitFile (which is included in the hotfix mentioned, but is also part of the .NET Framework 1.1 Service Pack 1). That method solved all my downloading problems.
On the other hand, the HTTPS part sounds more suspicious. Are your
certificates installed correctly?

Al

[hb]

Thanks for your help. A hint from adobe's forum's pointed me to this:

http://support.microsoft.com/default...;en-us;Q293792

The design of the web page was that such that user is redirected from
other pages that list the files to be opened. The file sent is passed
through session variables which are read and cleared in the Page_Load.
I'm guessing its a matter of speed. HTTP is quicker than HTTPS which
has the added burden of encryption.

Delaying the deletion of the session variables appears to resolve this
issue.

Does the HTTP vs HTTPS thing sound too far fetched?
"hb" <[e-mail]> wrote in message news:jun8d.122362$wV.49418@attbi_s54...

I am having trouble with creating a document server from a database using
asp.net.
It works on the development machine (win2k, iis5.0), but fails on the
production server (win2003, iis6.0).
The production server is not failing in all circumstances, however. The
behavior has the following characteristics:

1) serving of gif and jpg files work fine on both machines
2) serving of pdf files works on:
a) the development server through http - always (client on dev server or another machine)
b) the production server when sent via http
c) the production server through https when the client is also run on
the production server
and fails on:
a) the production server when sent via https

In the failing cases, the client gets a dialog box with the following
message:
Acrobat could not open 'xxx.fdf' because it is either
not a supported file type or because the file has been
corrupted (for example it was sent as an e-mail
attachment and wasn't properly decoded).

I find it strange that pdf says 'xxx.fdf' rather than 'xxx.pdf'. That is
not a typo. It is not an error in the document server either since the code is the same when it works and when it doesn't work.

After reading some of the comments on the forum, from people with similar
questions, I tried increasing the expiration from "immediate" to 5 minutes. I've also increased the page timeout setting to 90 seconds though this
document is small enough to be sent in well under 10 seconds.

The pertinent code is as follows:

Response.Clear();
Response.ContentType = "application/pdf"; // note this is image/gif or image/jpg for the other formats
Response.AppendHeader("Content-Length", ""+docSize);
Response.AppendHeader("Content-Disposition", "inline;
filename="+docName); // note, tried it with/without "inline; " inculded
it didn't have an observable effect.
Response.BinaryWrite(doc);
Response.End();

All suggestions welcome.

hb