I know its possible in .net, any help on how to do this in
classic asp would be greatly appreciated.
Regards,
Dean
*** Sent via Developersdex http://www.developersdex.com ***
After authenticating the user, read the file contents and then
1. Use Response.ContentType to set mime type.
2. Use Response.AddHeader to set file name
Response.AddHeader "content-disposition","attachment;
filename=fname.ext"
3. Use Response.BinaryWrite to send the file to the browser.
--
Bwig Zomberi
Just a note though - if the file is large, you may have to send it out in
chunks instead of all in one go. If you Google for "ado stream binarywrite"
you'll find plenty of examples of how to do this in ASP.
--
Dan
I can't get the documents to open in the browser, they
automatically save. Ideally i would like to open the files in
a popup window if thats possible.
my code looks like this, the inline just ins't doing anything.
Response.AddHeader "Content-Disposition","inline; filename="&
file
Regards,
Dean g
This depends on the browser setting. You may have prevented the show
dialog box setting and set it for automatic save. Try with another
browser or in another computer.
> Ideally i would like to open the files in
> a popup window if thats possible.
In the link that connects to this ASP, use target="_blank".
Omit the Response.AddHeader.
Depending on the mime type and related-settings, the browser may display
the contents in a new window. If browser is configured to load the
content outside the browser in the native application, it may do so.
>
> my code looks like this, the inline just ins't doing anything.
>
> Response.AddHeader "Content-Disposition","inline; filename="&
> file
It provides a file name for the contents sent by the ASP page.
Otherwise, you have to enter a name or the browser will give a name.
--
Bwig Zomberi
Its working well now.
Dan, I wanted to implement something like this. However, for very large
file downloads and slow user connections, the script will have to be
running for a long time. IIS will kill any request after some time. Do
you or anyone else know how to avoid that?
--
Bwig Zomberi
Look at documentation for the Server.ScriptTimeout property :)
--
Dan
No, Dan. There is a limit for that too. Imagine a 700 MB ISO file and
the user is on dialup. It will take several hours. IIS will kill the
request.
--
Bwig Zomberi
Surely a protocol designed for larger files would be more appropriate?
Like FTP maybe?
Dooza
FTP sends passwords unencrypted. SFTP is not available on all hosting
servers.
--
Bwig Zomberi
In that case, don't do it :P
As Dooza points out, FTP is more appropriate for something like this.
Any application you build will have limits - you just have to figure out
what is feasible and use alternate means for anything that falls outside of
the parameters you come up with.
--
Dan
Either use anonymous FTP (if the files were going on an web site without
authentication), or use a custom FTP system with a short term unique ID in
the filename request to authenticate against an existing request via the
authenticated web application. Or come up with some other custom
authentication scheme.
Hosting large files on a standard public hosting package is obviously not an
appropriate use of said hosting. In many cases it'll likely be a violation
of the hosting T&C anyway. If you have a VPS or dedicated server then you
have a lot more flexibility and should be able to set up SFTP, FTP+SSL, or
any of a number of options for hardening FTP (or any other
application/protocol designed for handling large files).
If you're going to pick holes in every suggestion provided we're going to be
here indefinitely :P
--
Dan
I just needed a second opinion that I have done everything that can be
done with a script. I am not picking holes. I had already tried
everything you had suggested when I was faced with same problem as the
OP. I provided the solution to the OP based on that experience.
The files I handle are less than 70 MB and they are on a shared hosting
server. However, I did not go for the ASP download solution because of
slow downloaders. Currently, http folder passwords are used. This is
also unsatisfactory, credentials are sent as plain text.
--
Bwig Zomberi
For the latter issue, you will either need to look into SSL (which is often
difficult with shared hosting as it requires a dedicated IP address for the
site, or a SAN certificate covering all required virtual servers on a single
IP), or NTLM/Integrated Authentication (which IIRC doesn't work if there are
proxy servers involved between the browser and server).
--
Dan
i Think i need to determine the appropriate MIME type from
binary data, but don't really have a clue where to start.
Check the extension of the file. If it is "PDF" or "pdf", then set the
mime type to "application/pdf".
Response.ContentType = "application/pdf"
A list of popular mime types:
http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx#Known_MimeTypes
For unknown mime types, I think you need to use "application/octet-stream"
--
Bwig Zomberi
This is probably the best solution. IE7 and higher do have "MIME sniffing"
too which will attempt to determine the real MIME type from the file header,
but this seems to fail from time to time.
--
Dan
Just set it to application/octet-stream as Bwig suggested, then the browser
can deal with as it sees fit.
Trying to roll your own MIME sniffing code in ASP is going to be a mess -
without a COM component that you can program against to do it for you it's
not worth even starting. The MIME sniffing I was referring to is already in
IE7 and IE8, they will attempt to determine the appropriate application to
open a file that is downloaded.
--
Dan
That will be very expensive in terms of server resources. It will not be
scalable.
--
Bwig Zomberi
Thanks for the help guys, i just wish i knew why half the pdf
files display garbage on the screen even though they are
genuine pdf's. i guess thats a question for another group
though.
regards,
Dean
I had this problem with Opera. In a newer version, it got solved.
Just ensure that you set the content type properly on the server-side
and you are not writing anything other than what is in the PDF to the
browser. To be sure that the entire ASP code is between one set of <%
and %>. Do not use nested code. Do not write any HTML or set any cookies.
On the client side, ensure that Adobe Reader is installed properly and
plugins are available for all browsers.
If the problems persist, then it is problem with the PDFs. You could go
to alt.txt.pdf. However, you will need to host the PDF and provide a
link so they can check it out.
--
Bwig Zomberi
The other thing you can do is use Response.Buffer = true, and then prior to
sending the headers clear the buffer first just in case there are any CR/LF
characters from inline ASP above that piece of code. Or just make sure you
always put inline ASP code fully inline, eg.
<%
blah blah
%>
<%
more blah
write headers
write binary data
%>
will actually put a single CR/LF combination before the data, because there
is a CRLF outside of the ASP tags. The same can be written as
<%
blah blah
%><%
more blah
write headers
write binary data
%>
and not insert the CR/LF.
It's also worth checking this wherever you send out a DOCTYPE headers in
normal HTML, if the DOCTYPE isn't on the first line of the output then some
browsers will ignore it.
--
Dan
I think that if you use two sets of <% and %>, it adds a new line
character, which will totally wreck the PDF. It should be like
<%
clear
buffer
content type
header
binary write
flush
%>
No spaces before or after the delimiters.
--
Bwig Zomberi
> I think that if you use two sets of <% and %>, it adds a new line
> character, which will totally wreck the PDF. It should be like
>
> <%
> clear
> buffer
> content type
> header
> binary write
> flush
> %>
>
> No spaces before or after the delimiters.
Use:
Response.Clear
....
Response.end
For years now
[last correction date of the inc file 21/5/2005]
I have succesfully used this:
function streamPdf(strFileName)
Response.Clear
strFilePath=server.mappath(strFilename)
Set objStream = Server.CreateObject("ADODB.Stream")
objStream.Open
objStream.Type = 1
objStream.LoadFromFile strFilePath
Response.ContentType = "application/pdf"
Response.BinaryWrite objStream.Read
objStream.Close
Set objStream = Nothing
Response.end
end function
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Nope, only if you put a new line between the tags. Feel free to try it out -
I've already done so on IIS6 and there is no implied newline at tag
ends/starts.
<%
blah
blah
%><%
blah blah
%>
does not add a newline.
I often use includes too, so for instance will do things like
<%
blah blah
%><!-- #include file="file.asp" --><%
blah blah
output binary data
%>
and again there will be no newlines before the binary data.
--
Dan
Your code does not add a new line. I usually put separate the <% %>
pairs for readability of the code. That adds a new line. The OP may be
doing the same in his code. He may not immediately see that you have
neatly avoided that pitfall by keeping it together;-)
I have faced a similar problem with writing RSS feeds using ASP. The
first line of XML files should start with <?xml .... or something. My
regular code convention would break that.
--
Bwig Zomberi
I thought I'd made it clear enough in my earlier reply, and that you were
stating I was wrong, hence the above followup. If you look at my 2 examples
you can see the difference, and that was my point.
> I have faced a similar problem with writing RSS feeds using ASP. The first
> line of XML files should start with <?xml .... or something. My regular
> code convention would break that.
Ah, yes, RSS, that's another place I learnt to not put newlines outside of
code blocks ... :)
--
Dan
Thanks alot
Speed reading. My bad.
ContentType, not DocType, your bad.
Another thing: The PDF ng is comp.text.pdf, not alt.txt.pdf. My bad.
--
Bwig Zomberi
Apologies for the bads. Just looked it up. I will promise never to use
it again.
--
Bwig Zomberi
I hope that isn't a promise not to use DOCTYPE declarations in your HTML
pages ;)
--
Dan
No, you are right. That was clearly in a different context. I thought
you suggested doctype for PDF files.
--
Bwig Zomberi
I guess I need to break my replies up a bit more then, but in my defensive I
did put "normal HTML" in the same line :)
It's a shame this newsgroup will be gone soon :(
--
Dan