I have a super serious issue which has completely stumped me.
I was playing with the IIS value in 'Maximum allowed content length' which can be seen in (IIS 7.0 on windows 7) IIS > Request filtering > right click white space > Edit feature settings. I set this to 30 billion to experiment with uploading large files then restarted IIS.
Now ALL my systems work until a form is submitted. The moment the submit button is clicked the destination page loads with this error:
Request object error 'ASP 0104 : 80004005'
Operation not Allowed
/SERS/OHSIndex.asp, line 20
The code on line 20 is simply request.form - where ever I go the line number will change to which ever line the first request.form is.
So I set this 'Maximum allowed content length' back to 30000000 Bytes and did a full re-start. My issue is still there. Hopefully someone knows how to solve this, I am completely stuck and all of my systems are inoperable. Help..
Maximum allowed content length is not for uploads, but for maximum response-length IIRC. Anyway, it seems you changing back your settings doesn't work. You may want to try editing this directly in the %windir%\system32\inetsrv\config\applicationHost.config file.
Alternatively, you can restore an old version of the config file, to restore the setting:
http://jshidell.com/2012/03/27/fixing-corrupted-applicationhost-config-file-in-iis-7/
Thank you all for your time and ideas. As I said this was a complete show stopper for me, it simply had to be fixed ASAP. After several hours of research I came to the conclusion I had a very rear issue since I could not find anybody having the same issue. The error indicating it was something to do with fileSize, maxEntity, exceeding form control limit, exceeding the limit for a form etc..... Well it simply was not any of those. When I set an unusually high 'Maximum allowed content length' value and restarted IIS it tripped something out in a big way which could not be reverted. A light bulb moment said IIS needed to be uninstalled and them re-installed. This did fix it.
To answer the good people who asked questions:
no enctype='multipart/form-data' was not being used FYI .form and .querystring were problematic
changing the the 'Maximum allowed content length' property in IIS is the same as editing the applicationHost.config file, there is no difference. But yes I did check this, the values were the same as they should have been. As I said in my original post setting this value back to the default 30MB (for IIS 7)) did not chnage anything
200k is the default setting for IIS 6. I did mention I was using IIS 7.0, the default setting for 7.0 is actually 30mb. Also the setting is not called 'AspMaxRequestEntityAllowed' in IIS 7 its called maxAllowedContentLength
Related
I am having a simple blank page without any source code.The page also taking very long time to come.I am not able to understand the reason behind this.
The domain is getting a high requests.
What exact settings needs to be done in iis 7.0 so that it will be faster.
Please help.
ASP.NET pages always have an initial delay when the first request is made after the file has been created/edited/uploaded because the server needs to recompile them, however it shouldn't be more than 2-3 seconds in practice, and does not affect subsequent pageloads.
The only thing I can think of is an overloaded server. Assuming you're on a shared hosting package then I recommend you find another ISP. If not, then I'm afraid there's a lot more to it than just a "page pages load faster" switch hidden away.
I've been trying to upload some avi files by using several methods.
First I've tried using ADOBE's ADDT "UPLOAD FILE" to upload *.avi files, everything was ok, until I've tried to upload a 131.5M video. When the size of the video is less than 40M, there's no problem, but when the video is bigger is where the problem starts. So tried different methods, jquery plugins, etc, with the same result.
The server in which the movies should upload is running under IIS7.
Making some search over the internet, I've found that the php.ini should be changed, so I have the following related values changed:
max_file_uploads:20
max_input_time:240
memory_limit:256M
post_max_size:256M
upload_max_filesize:256M
Also in the SNAPIN of IIS under "REQUEST FILTERING" I've changed the value to 300000000 (300M).
I think it has something to do with the time the upload is taking, because sometimes I can see in the temp folder a parcial upload of something between 25 and 47M
I don't think that the php upload scripts are the problem, but something on the server side.
I finally discoverd which was the problem. In php.ini was the "*max_file_uploads*". First, I double it's value, from 20 to 40, which gave me 40 minutes timeout for an upload. Then I put in 200 which gave all the time needed to complete a 131.5 MB avi upload.
After finding this (I was moving all the related parameters to see what would happen if...) I decided to check on php.net to see what was the official definition for "*max_file_uploads*" which is:
"The maximum number of files allowed to be uploaded simultaneously. Starting with PHP 5.3.4, upload fields left blank on submission do not count towards this limit.".
I'm completely confused why this worked, but my php.ini values are now this:
max_file_uploads:200
max_input_time:14400
memory_limit:1.01G
post_max_size:1G
upload_max_filesize:999M
Beside, moved in the IIS in Request Filtering in the IIS section of the server (using IIS 7 manager), the value for max allowed content length to 1GB.
Want to thank Alykhalid for the time and advices.
Did you increase the value of the max_input_time, what is the new value? Also try to increase the value of the CGI Time Out. Also look at this blog post for PHP time out issues.
A site have run ok for some time. But recently, when I upload a image, it is always raising this error:
An unrecoverable error occurred. This form was missing from the server cache. Try reloading the page and submitting again.
The first time i uploaded the image is ok. but when I create the second article and upload a image, it shows the above error. And the upload button disappeared.
Does anyone konw how to correct it and what's the reason of this error emergence ?
Apparently the problem is not Drupal. Most likely a setting on the server. If you use hosting services. please contact support, they may be something advise. Also recommend looking into the FAQ page the module loads the image coordinates.
Also, to test this problem, try to move the website to your local kompyuter and test does not appear whether this problem. Good luck. And update all the modules before actual sosoyaniya. Poeksprimentiruyte module load module dev.
Some other users have had the same sort of issue. See this thread on Drupal.org and this question at Drupal Answers.
Try to disabling caching under admin/settings/performance and set minimum lifetime to none. Also try clearing the caches on your site and in your browser and try again.
The problem is in cache_get() function inside includes/cache.inc file.
At line no. 42, there is a check :
if (isset($user->cache) && $user->cache > $cache->created)
Time of user cache, is always coming as bigger than cache's creation time. That is why, this function returning zero and file is not uploaded.
However I could not find the solution yet.
I'm more into the LAMP stack, but I've been asked to work on a site that is running Windows and IIS 2008. I'm a beginner with IIS, so please be patient with me on this, and please ask me to provide more information if that is needed to determine.
I read the answer here (Slow first page load on asp.net site), but it seems like if I go to the site with one browser it takes long to load the first page, then fast on all other pages, then if I open up another browser, it's the same thing, so it's not something that is saved on the server, but per session?
Is there a way to have the application running at all times?
Right now it is taking 12 to 15 seconds for the first page to load.
I have access to the WebControlCenter and FTP.
I would look in the Global.asax page and see if there is anything going on when a session is started. There usually is a method in there called Session_Start that is called whenever a session is started. Also, it might have to do with the site being configured in debug mode. You can change the web.config setting to false, which has a big impact on performance.
I'm familiar with the phenomenon described in the question you've linked to, but your what you're describing does seem a bit odd.
firstly- try Jeff's suggestion and see if indeed there's something at the beginning of the session which slows it down.
If not- try answering this-
1. is the first page always slow or only on first access to it?
2. what happens if you open another tab in the browser (not a different browser)?
3. it's possibel that the page contains some heavy resources (like images, script files etc.) which are only downloaded on the first access to the page. try tracing your http responses you get and see what their sizes are.
4. try to enable trace on your web page to see the events which are taking the longest time (on aspx you need to add 'Page Trace="true"' to the page declaration)
hope one of these helps...
Have you tried a http debugger here? Lots of things could be going on here, but the fact that you get different behavior by using different browsers indicates it is probably some particular resource that is overweight.
My website would like users to upload their photos...but how do I keep our server safe from harm? Allowing only JPGs should avoid virus trouble, but what if someone selects a 10Gb file - will that slow the whole website down?
We're using Classic ASP and IIS6 (sorry, but that's how it is, can't change that!). Previously we have used a DLL from a company called Persits to handle uploads. However, it would be helpful to other people if we extend this discussion to other languages/technologies too.
ASPs cannot detect the size of a file until it has finished uploading, so thats a pain. Or can I check content-length in the HTTP header before I start the transfer?
Q1. Are there any other ways someone could abuse the upload facility?
Q2. How can I limit the danger to keep the site running and the server safe?
Thank you.
In Persists, you can set the maximum filesize a user can upload:
Upload.SetMaxSize 100000, True
The "True" above shows that the file is to be rejected if over the Max size. If set to False then the file will be trucated.
See http://www.aspupload.com/object_upload.html#SetMaxSize
If you were using ASP.Net you can specify a maximum size of file in web.config (or machine.config), and ASP.Net will throw an error after the size is exceeded in the upload. That is to say, if you specify a limit of 4Mb, and someome tries to upload a 100Mb, .Net will complain as soon as it has uploaded more than 4Mb.
The property in question is maxRequestLength, which accorsing to MSDN "Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server."
For example.
<configuration>
<system.web>
<httpRuntime maxRequestLength="4000" ....
I am not sure if there is an equivalent in classic ASP though.
There is a great component that uses Flash to upload files. Check it out
http://www.codeproject.com/KB/aspnet/FlashUpload.aspx
This appears to enforce file upload size: http://www.aspupload.com/
I am not sure how it handles it.
I've just found an article on how to limit size using a setting called 'AspMaxRequestEntityAllowed' in IIS:
http://www.banmanpro.com/support2/File_Upload_limits.asp
However, it doesn't work - my server already has that setting at 200k and yet we are currently uploading 1Mb files ok!
You can reject the oversized requests at the IIS level before they even get to your application by using Microsoft's UrlScan tool: http://technet.microsoft.com/en-us/security/cc242650.aspx
For IIS 6, it looks like you may not even need that. You should be able to set the MaxRequestEntityAllowed and ASPMaxRequestEntityAllowed metabase properties to your desired maximum value and the requests will be cut off at that point.