I have a user control on an ASP.Net page (that is using Master Pages) inside an UpdatePanel. This control has several functions, including buttons. The control works fine, except for one link where I'm trying to send a file to the client when they click on it.
The control is instantiated with an object which is used for display, action, and optionally serialized for transmitting to the client. I've sent files before, even in this project, but not from a UserControl, and not behind a UpdatePanel. The browser is acting as if I'm not even clicking on the link even though I can step through the code and I know it is working.
Response.Clear()
Response.AppendHeader("content-disposition", "attachment; filename=assignment.ics")
Response.ContentType = "text/xml"
'serialization code goes here
Response.Write(seralizedObject)
Response.Flush()
Response.End()
I've tried Response.Close instead. I've tried using Response.OutputStream.Write as well. Nothing seems to be working. Is what I'm trying to do even possible? Or do I need to devise some way to redirect to another page that will then send the file?
UPDATE: In view of the answer received, I've changed my implementation to point to another URL (an ashx file) to actually send the file. It works, but it isn't ideal. I'm still open to other suggestions on this one.
If an UpdatePanel doesn't work, I'd still like to 'internally' send the object to another file (like an ashx file) that could then send the file. Right now I'm using the URL querystring to send enough information to rebuild the object in my ashx file. Needless to say, that isn't a very pretty solution.
You can't stream a file to the client with an update panel, for various reasons. File streaming doesn't work in this AJAX scenario. Try removing the UpdatePanel and to verify it works without, and then use conditional updating. See this for more information.
Related
I'm implementing resume download capability in ASP.NET by following the MSDN example
However, I've made a few changes:
In the aforementioned example, Download button on the HTML page makes a GET request. My Download button on ASPX page makes a POST request.
And instead of the handler page DownloadHttpHandler.ashx.vb, I have Download.aspx.vb and this calls the appropriate function in DownloadFile.vb.
The problem is downloads do not resume in Internet Explorer 10. Upon closely inspecting the requests, I found that the Download button on my ASPX page makes a POST request. However as mentioned before, the Download button on the HTML page makes a GET request.
To further confirm if GET/POST makes any difference, I changed the GET to POST (in the original MSDN example). This was the only change I made. And as expected, downloads do not resume in Internet Explorer.
While searching for similar issues, I found this example. And even here only GET/HEAD requests are allowed and all other types (like POST) are explicitly not allowed.
So, if I'm not wrong, only GET requests are supported. Why?
In the code that you referenced, it is the logic required by the original post to use only GET or HEAD requests. In general, you can use
request.HttpMethod
to check for POST, GET, DELETE, PUT etc requests.
For understanding more about headers, I suggest this
I also suggest to go over this to understand HttpMethod in general.
I am developing a web app with an ASP server side and I use an iframe for data push.
An ASP handler flushes every once in a while some javascript to the iframe:
context.Response.Write("<script language='javascript'>top.update('lala');</script>");
context.Response.Flush();
My problem is that sometimes, when I receive the data, I don't get the full text. For example I will receive this : update('lala');
One workaround I have is to have a thread flushing '..........' every 500ms. (Then I will receive script>...... which will complete my javascript.)
However I am sure there must be a way to have Response.Flush() sending the whole chunk of data. Does someone have an idea on how to use properly Response.Flush() ?
Thank you!
Apparently after tons of google searches, I found the answer. The IIS server was compressing the output with GZIP, then it will seem to ignore all Response.Flush calls.
This is turned on by default in IIS7 and on Windows 7. If you disable it, it works fine.
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.
I've recently upgraded a page on our server from classic asp to asp.net
The page recieves postdata and saves it to a file. The page is used by many of our clients and the url (to the asp page) is hard coded into their software. This means that i cannot simply swap the old page out for the new one.
I'm trying to find a way to redirect clients from the old url to the new one.
I know you can do a simple redirect using IIS, but this does not cause the postdata to be redirected.
I've tried setting the file to a 307 temporary redirect, this works when the data is in the formdata but other post requests such as ones using the msxml library do not work.
Basically i need to find a way in IIS to forward a post request from one page to another without losing any of the body.
If the two pages are within the same application, you can use Server.Transfer. This just shifts the processing from the old page to the new one, and maintains all of the request data.
The best way i found was to use the temporary redirect code in IIS, although this didn't work for postdata originating from the msxml library. In the end i had to write a COM library in .NET to do the hard work using the system.encoding libraries and then reference the COM library in asp
You can always program (in asp.old) a loop that goes through all the form-data and insert a record with all the values in the database. You then redirect the user to your aspx-page with the id of the row in the database as a querystring parameter. Be careful if the form-data is sensitive, to apply some sort of security to make sure users wont "steal" others data by changing the querystring.
Redirect Reference (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/41c238b2-1188-488f-bf2d-464383b1bb08.mspx?mfr=true
I've been using user controls extensively but never use a HttpHandler and was wondering if I am doing something suboptimal or wrong
Unfortunately your question is a little like "Should I use a sandwich or a cement mixer". HttpHandlers and User controls are completely different things.
HttpHandlers are used to process HTTP requests. For example, if you wanted to dynamically create an RSS feed, you could write an HTTP handler that handles all requests for ".rss" files, creates the output and sends it back to the user.
User controls are used within ASPX pages to encapsulate units of functionality that you want to re-use accross many pages.
Chances are, if you're using user controls successfully, you don't want to use HttpHandlers!
Basically a user control is a piece of server logic and UI. An HTTP Handler is only a piece of logic that is executed when a resource on your server is requested. For example you may decide to handle requests for images sent to your server through your own handler and serve images from a database instead of the file system. However, in this case there's no interface that the user sees and when he visits a URL on your server he would get the response you constructed in your own handler. Handlers are usually done for specific extensions and HTTP request types (POST, GET). Here's some more info on MSDN: http://msdn.microsoft.com/en-us/library/ms227675(VS.80).aspx
Expect a better answer (probably before I finish typing this) but as a quick summary.
A user control is something that can be added to a page.
A HttpHandler can be used instead of a page.
Just to clarify the question. I was reading the Hanselman post
http://www.hanselman.com/blog/CompositingTwoImagesIntoOneFromTheASPNETServerSide.aspx
and thinking that I would never solved the problem with a HttpHandler, maybe with a simple page returning a binary content.
This led me to think that I should add HttpHandler to my developer tool belt.
Even an Asp.Net page is an HttpHandler.
public class Page : TemplateControl, IHttpHandler
A user control actually resides within the asp.net aspx page.