My web application allows authorised users to upload videos using the ASP.NET WebForms FileUpload web control, which in the past have been around 100-200MB. I had to obviously make some changes to the web.config so that files of this size could be uploaded.
However, the authorised users now want to upload video files which are 500MB+
The maxAllowedContentLength has now been set to 629145600 (600MB).
However, when uploading the videos, after a while the page responds with:
Page not found
This only happens with large videos, so I know this issue has something to do with the file size.
Why is this happening? And also, should I really be increasing the limit to 500MB+? Is there a better way of getting such large files onto the web server?
Check out this blog post by Jon Galloway, its a bit old but still relevant:
Large file uploads in ASP.NET
Its got answers to your questions about:
page not found
setting the correct maxAllowedContentLength
There's recommendations for various controls you can use, both free and commercial.
I've used the flash control and it worked great.
Alternative Solution
Provide an FTP area for each user to upload too.
It allows users:
easily batch upload many files (harder in the browser)
takes advantage of resume on disconnect
Then you provide a GUI for the user, to consume the files.
Have you considered using jQuery File Upload https://github.com/blueimp/jQuery-File-Upload/ there are versions available for .net and mvc (see the git hub wiki). It takes all the heart ache out of implementing large file uploads in .net and provides a lovely interface too. Since discovering this a while ago I never use anything else! I've successfully implmented a few times now and seen uploads ~2GB working successfully.
Related
I currently have an asp.net page which a loggd in user goes to and theres a bunch of dynamically generated links to zip files that he or she owns and can downloads.
Currently they click download and I have no way of knowing if it completes succesfully etc so can't log it. I do log the attempt.
Is there are good download manager or solution I can use so they will have progress bars on the site, they can queue multiple ones up and most importantly I can track failed and successful downloads.
Thanks!
You cannot do this with pure asp.net and ajax as the browser sandbox doesn't give you access to the users computer to save the files.
So you need to use some sort of plugin.
Here's an ActiveX plugin that does what you want but it only works in IE and its expensive. I wouldn't go there...
As you are using Asp.net, a better option would be to write your own download utility in Silverlight.
Bare in mind though, that you'll probably annoy some of your users by forcing them to use your downloader and it will take considerable effort to get a high speed, robust downloader that can compete with the existing browser download managers out there. eg Free Download Manager
I might end up having to build this, but it would be nice if there is a solution already...
I need to add functionality to a client's web page to allow them to upload files, and then to view and download them. We also need some form of authentication mechanism to restrict who has access to which files. I have used Neat Upload in the past and have found that it works pretty well, but it only handles upload. If there is a control that does everything, that would be pretty nice. Has anyone seen or used anything like that? I am working in ASP.Net. Our server is IIS 6, but I cannot confirm which version of IIS the client is using.
I did some more searching, and found this. I think it will fit our needs perfectly
edit: The link didn't come through. The solution is FileVista, at http://www.gleamtech.com/products/filevista/web-file-manager
I would recommend using Neat Upload or some other upload component and integrating ASP.NET membership services to manage permissions.
I have a piece of my site being built for me that works like this... when you click a song, the song loads in the player and plays it.
I'm being told by the guy who's developing it for me that Asp.Net does not support 320kbps files, so that's why the player isn't working. This seemed a little ridiculous so I did some research on it and couldn't find anything that says so:
http://msdn.microsoft.com/en-us/library/cc189080%28VS.95%29.aspx
He found this on that page:
24 bit audio will return silence.
But that's under the WMA section, not the MP3 section, I can't even tell if they're 24 bit or not anyways... The only info I have is that the songs are 320kbps and they're all .mp3 files. I can provide more info if you tell me where to look. Please let me know why he would be saying that these files can't be streamed... he says he's tried 128kbps and it worked, but that these are incompatible.
Thanks,
Matt
I'm being told by the guy who's
developing it for me that Asp.Net does
not support 320kbps files, so that's
why the player isn't working.
You're right, he's wrong. That page is irrelevant.
Asp.net doesn't care -- doesn't know! -- what's inside the file. If the connection doesn't overtax the available bandwidth, you're fine.
Assuming you're using a static file and not a dynamic one, ASP.NET will never even see it. All references to static files are handled by IIS, without involving the ASP.NET runtime.
However, by default static files aren't streamed. Instead, they are sent at the maximum speed that the connection will support. If you want true streaming, you will need to add an appropriate plug-in to IIS, or use something like Windows Media Server.
I've recently started embedding JavaScript and CSS files into our common library DLLs to make deployment and versioning a lot simpler. I was just wondering if there is any reason one might want to do the same thing with a web application, or if it's always best to just leave them as regular files in the web application, and only use embedded resources for shared components?
Would there be any advantage to embedding them?
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
I doubting and questioning the validity of Easement's comment about how browsers download JavaScript files. I'm pretty sure that the embedded JavaScript/CSS files are recreated temporarily by ASP.NET before the page is sent to the browser in order for the browser to be able to download and use them. I'm curious about this and I'm going to run my own tests. I'll let you know how it goes....
-Frinny
Of course if anyone who knew what they were doing could use the assembly Reflector and extract the JS or CSS. But that would be a heck of a lot more work than just using something like FireBug to get at this information. A regular end user is unlikely to have the desire to go to all of this trouble just to mess with the resources. Anyone who's interested in this type of thing is likely to be a malicious user, not the end user. You have probably got a lot of other problems with regards to security if a user is able to use a tool like the assembly reflector on your DLL because by that point your server's already been compromised. Security was not the factor in my decision for embedding the resources.
The point was to keep users from doing something silly with these resources, like delete them thinking they aren't needed or otherwise tamper with them.
It's also a lot easier to package the application for deployment purposes because there are less files involved.
It's true that the DLL (class library) used by the pages is bigger, but this does not make the pages any bigger. ASP.NET generates the content that needs to be sent down to the client (the browser). There is no more content being sent to the client than what is needed for the page to work. I do not see how the class library helping to serve these pages will have any effect on the size of data being sent between the client and server.
However, Rjlopes has a point, it might be true that the browser is not able to cache embedded JavaScript/CSS resources. I'll have to check it out but I suspect that Rjlopes is correct: the JavaScript/CSS files will have to be downloaded each time a full-page postback is made to the server. If this proves to be true, this performance hit should be a factor in your decision.
I still haven't been able to test the performance differences between using embedded resources, resex, and single files because I've been busy with my on endeavors. Hopefully I'll get to it later today because I am very curious about this and the browser caching point Rjlopes has raised.
Reason for embedding: Browsers don't download JavaScript files in parallel. You have a locking condition until the file is downloaded.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
Regarding the browser cache, as far as I've noticed, response on WebRecource.axd says "304 not modified". So, I guess, they've been taken from cache.
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
You know that if somebody wants to tamper your JS or CSS they just have to open the assembly with Reflector, go to the Resources and edit what they want (probably takes a lot more work if the assemblies are signed).
If you embed the js and css on the page you make the page bigger (more KB to download on each request) and the browser can't cache the JS and CSS for next requests. The good news is that you have fewer requests (at least 2 if you are like me and combine multiple js and css and one), plus javascripts have the problem of beeing downloaded serially.
Is there a way to programmatically set the name of a file to be uploaded from a web page? I suspect that browser security restrictions make this impossible, but I'm hoping someone will prove me wrong.
I have a web application that needs to let the administrator upload HTML. The admin selects the HTML file, then the app uploads that file, plus figures out all the supporting files (images, stylesheet, etc) and uploads them too. There doesn't seem to be a way to programmatically upload the supporting files from a web page, since the user has to specify each file explicitly.
Currently I have a separate Windows app to do this, but it would be ideal to have this functionality integrated with the rest of the app. My back end is ASP.NET with C#.
There is no way to programatically grab files from a user's computer via the browser. This would be a security violation if a website could just grab things.
Yes you can (in modern browsers)...
You can get and set the value of HTMLInputElement.files.
See this answer.
No, you cannot do this without a client-side application or special plug-in.
Browser security doesn't allow the server to obtain information about the hard drive contents of the client.
You may be able to do this using some form of browser plug-in. This is more work for you (and there are potential security implications for this beyond those found when you just have users run your app). However, it may prevent a more integrated experience for your users. I'd hesitate to eliminate the application completely, though. Browser compatibility issues are common.