Display PDF from database without caching

[rolfejr]

I am trying to display a PDF in the users browser that is pulled from a
binary field in our database, and keep that PDF from caching on the
client computer. I can successfully pull the PDF and display it using
the following code:

Response.ContentType = "application/pdf"
Response.BinaryWrite objRS("Attachment")

where objRS("Attachment") is a reference to the binary field retrieved
from the database. However, I have tried adding virtually every header
known to have anything to do with caching, and I cannot seem to prevent
the PDF from caching in the client's browser. So then I tried to use
the adodb.stream object, as follows:

set objStream=server.createObject("ADODB.Stream")
objStream.Open
objStream.Type=1 'adTypeBinary
objStream.write objRS.fields("Attachment").value

Response.ContentType = "application/pdf"
Response.BinaryWrite objStream.Read()

This follows, more or less, several examples I've found on the web,
although most examples are reading a file into the stream, not a binary
field returned from a database. This code gives me the following
error:

Response object, ASP 0106 (0x80020005)
An unhandled data type was encountered.

I'm looking for a way to make the stream work, or any other suggestions
on how to display the pdf to the client without it caching in their
browser.

[Anthony Jones]

<ro*****@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

I am trying to display a PDF in the users browser that is pulled from a
binary field in our database, and keep that PDF from caching on the
client computer. I can successfully pull the PDF and display it using
the following code:

Response.ContentType = "application/pdf"
Response.BinaryWrite objRS("Attachment")

where objRS("Attachment") is a reference to the binary field retrieved
from the database. However, I have tried adding virtually every header
known to have anything to do with caching, and I cannot seem to prevent
the PDF from caching in the client's browser. So then I tried to use
the adodb.stream object, as follows:

set objStream=server.createObject("ADODB.Stream")
objStream.Open
objStream.Type=1 'adTypeBinary
objStream.write objRS.fields("Attachment").value

Response.ContentType = "application/pdf"
Response.BinaryWrite objStream.Read()

This follows, more or less, several examples I've found on the web,
although most examples are reading a file into the stream, not a binary
field returned from a database. This code gives me the following
error:

Response object, ASP 0106 (0x80020005)
An unhandled data type was encountered.

I'm looking for a way to make the stream work, or any other suggestions
on how to display the pdf to the client without it caching in their
browser.

You can't prevent the caching of the PDF on the client by modifying how the
PDF is streamed. At the end of the day the client sees the exact same
sequence of bytes.

What did you try in the headers. The following should prevent a cache from
re-using the content:-

Response.Expires = 0
Response.CacheControl = "private; max-age=0; no-cache"

You could also go with:-

Response.CacheControl = "private; max-age=0; no-store"

Also you could use a negative number for expires to make sure that a slow
clock on the client doesn't result in the content being cached. Browsers
using HTTP 1.1 will favor Cache-Control over Expiry date anyway.

How are you determining that a cache version is being re-used. The back
button on a browser for example may not be affected by any of these HTTP
headers.

[rolfejr]

I have tried the following headers:
response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
response.addheader "Cache-Control","no-store, no-cache,
must-revalidate"
response.addheader "Cache-Control","post-check=0, pre-check=0',
FALSE"
Response.AddHeader "Pragma", "no-cache"
Response.CacheControl="no-cache"
Response.expires=-1

I've tried various combinations of these as well. The way I am
determining whether or not it is cached is by clearing my cache,
loading the page, and looking at the cache - the PDF is there in the
cache still there. I'm not so concerned about the browser showing a
cached version instead of the latest version, I'm more concerned with
privacy. These PDF's contain sensitive information. I am worried
about someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their cache.
That's why I was wondering if by streaming the PDF if I could keep it
from saving an actual PDF file in their cache folder.

The interesting thing is that there are two pages involved - the first
is gerenated HTML that shows the list of available PDF's from the
database. I have successfully been able to prevent this page from
being cached with the following meta tags:
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="-1"

I have also added a cache-control:no-cache header using IIS on this
specific page (actually, all pages in this directory. The user clicks
one of the PDF links, and in a new window it opens the ASP page that is
application.pdf content type in a new browser window. Obviously I
can't put meta tags on this page, because it is not HTML - it's the
binary PDF, so I am stuck with HTTP headers. I will keep
experimenting, using your specific examples below and see what happens.
Anthony Jones wrote:

You can't prevent the caching of the PDF on the client by modifying how the
PDF is streamed. At the end of the day the client sees the exact same
sequence of bytes.

What did you try in the headers. The following should prevent a cache from
re-using the content:-

Response.Expires = 0
Response.CacheControl = "private; max-age=0; no-cache"

You could also go with:-

Response.CacheControl = "private; max-age=0; no-store"

Also you could use a negative number for expires to make sure that a slow
clock on the client doesn't result in the content being cached. Browsers
using HTTP 1.1 will favor Cache-Control over Expiry date anyway.

How are you determining that a cache version is being re-used. The back
button on a browser for example may not be affected by any of these HTTP
headers.

[rolfejr]

One other thing that is strange - if I look at my cache using internet
explorer (tools -options -(general tab, settings button under
Temporary Internet Files section) -View Files, then the PDF is not
there. The same thing is you navigate to C:\Documents and
Settings\username\Local Settings\Temporary Internet Files. However,
this is a special folder, and the actual files are stored in various
subdirectories in a content.ie5 subdirectory to the folder Temporary
Internet Files - windows just doesn't show it to you. So instead if
you navigate to \\computername\c$\documents and settings\username\local
settings\temporary internet files\content.ie5\ (windows no longer
treats it as a special folder) and search all files in this directory
and subdirectory, then you will find the PDF. Maybe I am just dealing
with the fact that this is just how internet explorer works, and there
is no way to prevent the actual file from existing on the client
computer?

[rolfejr]

By the way, I have the same problem with firefox - the cache is a
little more cryptic as there is no file extension, but nevertheless,
the file is still there, and is easily renamed and accessed.

[Mike Brind]

ro*****@gmail.com wrote:

I have tried the following headers:
response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
response.addheader "Cache-Control","no-store, no-cache,
must-revalidate"
response.addheader "Cache-Control","post-check=0, pre-check=0',
FALSE"
Response.AddHeader "Pragma", "no-cache"
Response.CacheControl="no-cache"
Response.expires=-1

I've tried various combinations of these as well. The way I am
determining whether or not it is cached is by clearing my cache,
loading the page, and looking at the cache - the PDF is there in the
cache still there. I'm not so concerned about the browser showing a
cached version instead of the latest version, I'm more concerned with
privacy. These PDF's contain sensitive information. I am worried
about someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their cache.

How will you prevent the user from hitting the "Save" button on their
browser/reader and saving a local copy of the file?

--
Mike Brind

[Dave Anderson]

Mike Brind wrote:

>These PDF's contain sensitive information. I am worried about
someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their
cache.

How will you prevent the user from hitting the "Save" button
on their browser/reader and saving a local copy of the file?

Those are separate issues. Many of us work in environments where such
behavior is covered under regulatory guidelines, such as HIPAA. There can be
legitimate handling of sensitive data that involves saving files.

In any case, the OP is making an effort to safeguard that information when
the user is following his/her protection guidelines. Your question is
irrelevant.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

[Mike Brind]

Dave Anderson wrote:

Mike Brind wrote:

These PDF's contain sensitive information. I am worried about
someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their
cache.

How will you prevent the user from hitting the "Save" button
on their browser/reader and saving a local copy of the file?

Those are separate issues. Many of us work in environments where such
behavior is covered under regulatory guidelines, such as HIPAA. There can be
legitimate handling of sensitive data that involves saving files.

In any case, the OP is making an effort to safeguard that information when
the user is following his/her protection guidelines. Your question is
irrelevant.

Huh? Irrelevant to what? Of course I realise it's a separate issue to
the OP's problem, but it's one I am interested in knowing the answer
to. Hence I asked the question. That's what other people are allowed
to do here. And before you say it, yes, I also realise, strictly
speaking, it's OT for this group. But then so are all the html/css etc
questions that get answered.

Sod it... I withdraw the question.

--
Mike Brind

[Anthony Jones]

<ro*****@gmail.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

I have tried the following headers:
response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
response.addheader "Cache-Control","no-store, no-cache,
must-revalidate"
response.addheader "Cache-Control","post-check=0, pre-check=0',
FALSE"
Response.AddHeader "Pragma", "no-cache"
Response.CacheControl="no-cache"
Response.expires=-1

Rather than mucking about with various headers lets just use the correct
headers for your requirement.

You want to attempt to stop the file from being cached at all. This could
be a problem for PDFs.

The correct code to acheive this is:-

Response.CacheControl = "private; no-store"

This informs all proxies between the origin server and the client not to
store a copy of the resource. It also tells the client that it should not
keep a copy of the resource. (no-cache actually means keep a copy if you
want but always check back with the origin server before using it)

The problem with this, at least with IE and PDFs, is that the implementation
doesn't appear to be able to handle rendering a PDF stream directly, it
needs to map the stream in to a file so despite the http headers saying
otherwise it is stored anyway. Why it isn't deleted after it has been
finished with I don't know it ought to be possible.

I've tried various combinations of these as well. The way I am
determining whether or not it is cached is by clearing my cache,
loading the page, and looking at the cache - the PDF is there in the
cache still there. I'm not so concerned about the browser showing a
cached version instead of the latest version, I'm more concerned with
privacy. These PDF's contain sensitive information. I am worried
about someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their cache.
That's why I was wondering if by streaming the PDF if I could keep it
from saving an actual PDF file in their cache folder.

The interesting thing is that there are two pages involved - the first
is gerenated HTML that shows the list of available PDF's from the
database. I have successfully been able to prevent this page from
being cached with the following meta tags:
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="-1"

I have also added a cache-control:no-cache header using IIS on this
specific page (actually, all pages in this directory. The user clicks
one of the PDF links, and in a new window it opens the ASP page that is
application.pdf content type in a new browser window. Obviously I
can't put meta tags on this page, because it is not HTML - it's the
binary PDF, so I am stuck with HTTP headers. I will keep
experimenting, using your specific examples below and see what happens.
Anthony Jones wrote:

You can't prevent the caching of the PDF on the client by modifying how

the

PDF is streamed. At the end of the day the client sees the exact same
sequence of bytes.

What did you try in the headers. The following should prevent a cache

from

re-using the content:-

Response.Expires = 0
Response.CacheControl = "private; max-age=0; no-cache"

You could also go with:-

Response.CacheControl = "private; max-age=0; no-store"

Also you could use a negative number for expires to make sure that a

slow

clock on the client doesn't result in the content being cached.

Browsers

using HTTP 1.1 will favor Cache-Control over Expiry date anyway.

How are you determining that a cache version is being re-used. The back
button on a browser for example may not be affected by any of these HTTP
headers.

[rolfejr]

That's basically the conclusion that I had come to - there is a
Microsoft support document (several, actually) on the problem of
downloading PDF's over an SSL, but I'm not using SSL - actually, in
this particular scenario, the client may or may not use SSL (inside
the company they don't - outside they do). Anyway, I will experiment
some more with the private; no-store heading - at least now I know the
correct header - thanks.

As to the question about how do you prevent a client from just saving
the PDF - you don't, and as has been stated already, that is
irrelevant. Of course someone can just save the PDF from their browser
- that's not the concern. the concern is someone ELSE pulling from a
users cache without their knowledge. Basically I am dealing with
people's pay stubs in PDF form, so if they want to save it, fine - they
can do whatever they want with it. I just don't want people pulling
OTHER employees pay stubs from their internet caches - at home, at
work, at the library, etc, etc.

Rather than mucking about with various headers lets just use the correct
headers for your requirement.

You want to attempt to stop the file from being cached at all. This could
be a problem for PDFs.

The correct code to acheive this is:-

Response.CacheControl = "private; no-store"

This informs all proxies between the origin server and the client not to
store a copy of the resource. It also tells the client that it should not
keep a copy of the resource. (no-cache actually means keep a copy if you
want but always check back with the origin server before using it)

The problem with this, at least with IE and PDFs, is that the implementation
doesn't appear to be able to handle rendering a PDF stream directly, it
needs to map the stream in to a file so despite the http headers saying
otherwise it is stored anyway. Why it isn't deleted after it has been
finished with I don't know it ought to be possible.

[Anthony Jones]

<ro*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...

That's basically the conclusion that I had come to - there is a
Microsoft support document (several, actually) on the problem of
downloading PDF's over an SSL, but I'm not using SSL - actually, in
this particular scenario, the client may or may not use SSL (inside
the company they don't - outside they do). Anyway, I will experiment
some more with the private; no-store heading - at least now I know the
correct header - thanks.

As to the question about how do you prevent a client from just saving
the PDF - you don't, and as has been stated already, that is
irrelevant. Of course someone can just save the PDF from their browser
- that's not the concern. the concern is someone ELSE pulling from a
users cache without their knowledge. Basically I am dealing with
people's pay stubs in PDF form, so if they want to save it, fine - they
can do whatever they want with it. I just don't want people pulling
OTHER employees pay stubs from their internet caches - at home, at
work, at the library, etc, etc.

Yeah um just don't do that then.

Rather than mucking about with various headers lets just use the correct
headers for your requirement.

You want to attempt to stop the file from being cached at all. This

could

be a problem for PDFs.

The correct code to acheive this is:-

Response.CacheControl = "private; no-store"

This informs all proxies between the origin server and the client not to
store a copy of the resource. It also tells the client that it should

not

keep a copy of the resource. (no-cache actually means keep a copy if

you

want but always check back with the origin server before using it)

The problem with this, at least with IE and PDFs, is that the

implementation

doesn't appear to be able to handle rendering a PDF stream directly, it
needs to map the stream in to a file so despite the http headers saying
otherwise it is stored anyway. Why it isn't deleted after it has been
finished with I don't know it ought to be possible.

[Mike Brind]

ro*****@gmail.com wrote:

That's basically the conclusion that I had come to - there is a
Microsoft support document (several, actually) on the problem of
downloading PDF's over an SSL, but I'm not using SSL - actually, in
this particular scenario, the client may or may not use SSL (inside
the company they don't - outside they do). Anyway, I will experiment
some more with the private; no-store heading - at least now I know the
correct header - thanks.

As to the question about how do you prevent a client from just saving
the PDF - you don't, and as has been stated already, that is
irrelevant. Of course someone can just save the PDF from their browser
- that's not the concern. the concern is someone ELSE pulling from a
users cache without their knowledge. Basically I am dealing with
people's pay stubs in PDF form, so if they want to save it, fine - they
can do whatever they want with it. I just don't want people pulling
OTHER employees pay stubs from their internet caches - at home, at
work, at the library, etc, etc.

Is password-protecting the PDFs not an option?

--
Mike Brind

[rolfejr]

Is password-protecting the PDFs not an option?

I wish. The pdf's are stored in the database by third party software,
so I have no control over how they are created. There may be some
option of pulling them out, password protecting them, then putting them
back in the database using some third-party pdf app, but I wouldn't
really know where to begin there...

[Mike Brind]

Persits ASPPdf allows you to open existing PDF documents and alter their
security settings, including applying passwords.

http://www.asppdf.com/manual_08.html

You would probably have to create a temp copy of the PDF on the server,
apply new security settings to that, then stream it and delete the temp
file.

The 30 day evaluation is definitely worth taking up. And no, I'm not on
commission - I have found it to be a very good product :-)

--
Mike Brind
<ro*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...

>Is password-protecting the PDFs not an option?

I wish. The pdf's are stored in the database by third party software,
so I have no control over how they are created. There may be some
option of pulling them out, password protecting them, then putting them
back in the database using some third-party pdf app, but I wouldn't
really know where to begin there...

[rolfejr]

Thanks for the reference, I will definitely look into it.

Mike Brind wrote:

Persits ASPPdf allows you to open existing PDF documents and alter their
security settings, including applying passwords.

http://www.asppdf.com/manual_08.html

You would probably have to create a temp copy of the PDF on the server,
apply new security settings to that, then stream it and delete the temp
file.

The 30 day evaluation is definitely worth taking up. And no, I'm not on
commission - I have found it to be a very good product :-)

--
Mike Brind
<ro*****@gmail.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...

Is password-protecting the PDFs not an option?

I wish. The pdf's are stored in the database by third party software,
so I have no control over how they are created. There may be some
option of pulling them out, password protecting them, then putting them
back in the database using some third-party pdf app, but I wouldn't
really know where to begin there...