I have a XML file stored in my IIS server. At several stages of the execution, my application retrieves this file. Basically it goes back to the server and gets the file again. The problem is that the application errors out because the file is not returned since it has been cached by the browser. It returns a 304 error. I know that when I pass a changing ID on the URL it is not cached; the problem is that this file has a fixed location and if I put something else in the URL it will not find it. So, is there a way to solve this elegantly? Changing the cache settings on the client is not an option. I use a WebClient object to request the file asynchronously.
Thanks!
304 is not an error, it is a "not modified" indication according to the HTTP response codes spec. You could try adding a random number or two to the querystring in order to attempt to get a 200 back instead.
Try setting the If-Modified-Since header in the request in order to do a conditional GET request. You can then check for the Not Modified (HTTP 304) status code and if it is modified then do something; otherwise let the browser use the cached version.
Here is a blog entry about this technique:
Setting If-Modified-Since Header in code
When you downloaded the XML file the first time, the settings of IIS told the client it was OK to cache the file. You can modify the cache settings for the directory containing your XML files so that it will tell the client not to cache anything.
Example:
<configuration>
<location path="myXmlFiles">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" />
</staticContent>
</system.webServer>
</location>
</configuration>
Related
Currently writing an API that accepts files using multipart/form-data. Below are my settings in Web.config. IIS is set to 1.0737GB limit and .NET is set to a 1.0485GB limit.
<httpRuntime requestValidationMode="2.0" maxRequestLength="1048576" executionTimeout="1000000" targetFramework="4.7.1" />
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
When I upload a file around 1.5-2GB in size I get a 404 back as described in the Microsoft documentation linked below. This is my expected response from the server. But, when I upload a much larger file, around 2.5GB+, I get a 400 Bad Request instead. I have been looking around for documentation to describe why this would happen and why I would not expect to always see a 404 instead, but have found nothing stating a 400 could be returned. The only difference between the requests is the files attached, nothing else is changed. To make the larger file size I also just zipped two of the original file that throws the 404 together. As additional details, the endpoint is covered in Unit and Integration tests that verify normal use case functionality. The endpoint works when manually tested with files below the IIS/.NET set limits. This behavior has also been seen when manually tested with a C# library project as well as Postman. Any help is greatly appreciated, thanks in advance!
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/
Clarification on my use case:
A clarification is that I'm not trying to increase the size limit of my requests, I just need to make sure anything over the size limit returns the same error. The documentation that will be publicly available needs to state the return value in case of error and currently it can be either a 404 or a 400 and I can't explain explicitly why in the documentation yet.
Thanks to help from all of the commenters, the following link provided by Brian Clink answered the question. https://sitecore.stackexchange.com/questions/11788/sitecore-media-file-upload-above-2gb-throws-bad-request-400
IIS forces the max size to be 2GB. So, for all requests less than 2GB that are larger than your custom IIS settings a 404.13 is returned. For all requests over 2GB a 404 is returned.
I'm getting the following error while redirecting one page to another web page:
"the page was not displayed because the request entity is too large.".
The page from which I'm redirecting to another page contains a huge amount of data, so basically I know the cause of the issue.
However, I'm looking out for a working solution for this. Secondly, when I researched this issue I found such kind of problem generates when any large file gets uploaded.
But I'm not uploading any large file, its just the page itself contains large data. Prompt solution will be appreciated.
I think this will fix the issue if you have SSL enabled:
Setting uploadReadAheadSize in applicationHost.config file on IIS7.5 would resolve your issue in both cases. You can modify this value directly in applicationhost.config.
Select the site under Default Web Site
Select Configuration Editor
Within Section Dropdown, select "system.webServer/serverRuntime"
Enter a higher value for "uploadReadAheadSize" such as 1048576 bytes. Default is 49152 bytes.
During client renegotiation process, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions
Reference.
I got it working by doing the following
Go to IIS.
Click on the server name
In the features (icons), chose the configuration editor.
Click on the dropdowns on the top with Settings
Traverse the path system.webServer -> security -> requestFiltering -> maxAllowedContentLength and set it to 334217728. (Then hit enter and then apply on the top right).
You can also restart the webserver for good measure.
After that I could upload my 150k database to phpymyadmin.
I also set post_max size to 8000 in php.ini in programs/PHP/phpversion/php.ini
It may be overkill for the sizes but it gets the job done when you've got big files.
For me, uploadReadAheadSize did not fix my issue.
I changed both of these settings in my asp.net web.config and finally the file uploaded for me:
<system.web>
<system.webServer
<httpRuntime executionTimeout="999999" maxRequestLength="20000" requestValidationMode="2.0" /> <!-- 20 MB -->
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="20500000" /> <!-- 20.5 MB - making it match maxRequestLength to fix issue with uploading 20mb file -->
</requestFiltering>
</security>
</system.webServer>
Another possible cause is an Authentication setting. Within IIS7,
Select the site under Default Web Site
Select Authentication
Select Windows Authentication and enable. Disable all others.
While Windows Authentication is still selected, click on Advanced Settings in the Actions pane.
Make sure Extended Protection is on Accept and check the Enable Kernel-mode authentication
I had the same error and the above fix did not work. I was only on HTTP (localhost)
However this fixed the 413 error
Set-WebConfigurationProperty -filter /system.webserver/security/requestfiltering/requestLimits -name maxAllowedContentLength -value 134217728
I did the above but still had no joy.
What fixed the problem for me was also upping the request limits:
- Select site in IIS manager
- Click "Edit feature settings" from right hand menu
- Insert 200000000 for "Maximum allowed content length"
In my case, the error occurred when downloading a file.
The reason was, that I had a code that explicitely sends an HTTP 413 to the client in an (erroneous) case.
(See here for details).
So be aware of the fact that setting an HTTP response code 413 in your code (or in a library that you are using) also can generate the OP's error message.
I am using IIS7.5, .net 4.0. I am working locally.
I have installed Application Request Routing, Web Farm Framework, WebDeploy and UrlRewrite to set up a reverse proxy. This works fine for the most part.
I have two websites:
DefaultWebSite (port 80, app pool: Default App Pool (.net 4)) and
Target (port 8085, app pool: TargetAppPool(my identity, .net 4)).
I have a rewrite rule on DefaultWebSite (created as directed on IIS.net) which redirects all localhost (port 80) traffic to localhost:8085 just as detailed in the above link. This works fine for most document types (.aspx, .xap, .htm, .ico) but a request to MyService.svc fails. It returns a 404.
To be clear:
When I paste localhost:8085/MyService.svc into a browser I get the requested WCF page.
When I paste localhost/MyService.svc into a browser I get a 404.
When I paste localhost:8085/MyIcon.ico into a browser I get the requested resource.
When I paste localhost/MyIcon.ico into a browser I get the requested resource.
.svc is the only document type that I've found that returns a 404.
I've got two pieces of info that might be of relevance.
App Pools. When I change the DefaultWebSite's app pool to TargetAppPool then the 404 becomes a 500 ("Failed to map the path '/'"). All other requests are successful when this change is made. Not sure if this relevant or not.
FREB (Failed Request Tracing) Log. I found a page (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx) which details the steps in a FREB log when a URL rewrite is more successful than mine (it fails later on). I've not been able to find out how to generate a FREB log for a successful rewrite (if that's possible) so I can only compare my FREB log to the one on that blog. I can see that their step 21 (URL_CHANGED) in my FREB log but not 22 (URL_REWRITE_END). I've not got enough experience with these logs to notice anything more significant than that (suggestions welcomed).
My main question is: does anyone know why just URLs requesting .svc resources are not being rewritten?
A secondary question is: does anyone know how to generate a FREB log for successful request (if it's even possible)?
Thanks
Update:
I have changed the architecture to try to get more info.
I have moved the Target website to a different PC on which I have installed Microsoft Network Monitor to capture the incoming traffic.
Before I changed the url-rewrite rule to point at this new website I got the correct response when I made a request to MyService.svc on the new PC. Fine.
As soon as I changed the rewrite rule to route the request to the new Target website then it responds as before (404). I have made both POST and GET requests. There is no sign of any of the requests in the Network Monitor log (all other calls -200, 404 or otherwise- appear in this log).
This leads me to think that there is something incompatible with url-rewrites and *.svc requests. I tried making a request to MyService.asmx (having created this file) and it correctly returned a page, so it is limited to *.svc. Any ideas?
The solution to this is in the config file of the Target web site.
In web.config (in the Target application) there is a section which read:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>.
I changed this to read:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />.
Credit must go to http://forums.iis.net/post/1956671.aspx for this (although s/he claims it is the proxy's config which needs to be changed, but I found it be the Target app, not the proxy server).
If you still can't get it running, make sure you don't have the WCF handlers on the website which acts as the reverse proxy.
I disabled this by adding this web.config of the reverse proxy:
<system.webServer>
...
<handlers>
<remove name="svc-ISAPI-4.0_64bit" />
<remove name="svc-ISAPI-4.0_32bit" />
<remove name="svc-Integrated-4.0" />
</handlers>
</system.webServer>
Because the rewrite appears to work for all resources except when the extension is .svc I would say this would be the area to concentrate on.
I would imagine that the rewrite rules are matching your other resources, but not your service, and because these are usually regular expressions (which are often complicated) I would say it would be worth testing any rules you find with your urls. Details of how to find the regular expressions for an UrlRewrite can be found here.
It is also probably also worth looking at any outbound rules with the same mindset.
I am getting the following exception when calling a web service operation in my .NET application:
System.Net.WebException: The operation has timed out at
System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest
request) at
System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest
request) at
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters) at
org.wvi.hrmgmt.HRManagementServiceserviceagent.LoadReducedTemplate(LoadReducedTemplateRequest
LoadReducedTemplateRequest) at
org.wvi.mgmt.hr._ServiceClient.UploadReducedTemplate()
Basically, a user uploads a file into the web server and the binary contents of this file is being passed as one of the input parameters when calling a web service operation. The size of the file is 1,397 KB and if I choose to process this file, I am getting the exception. Whereas, processing a file with a relatively smaller size, supposed 127 KB, gives a successful response.
I have done the below steps in order to solve the dillema:
Setting the web service timeout to infinite. -> Not getting an exception and any response
Adding Response.Close() -> Not getting any response
Editing the web.config in the IIS server and adding the following lines: -> Still getting the exception
<system.web>
<customErrors mode="Off"/>
<httpRuntime executionTimeout="600" maxRequestLength="16384"/>
<sessionState timeout="540"/>
</system.web>
However, to no avail, I'm still getting the above exception. I am using a Javascript plugin called AjaxUpload from GitHub and I can't figure out whether they have file upload size limit. Besides, I have checked the file if it is being uploaded on the server and it does, therefore, the issue may not be because of that plugin.
Another issue is that I am getting the same exception when uploading the file after a period of time the web page has been opened. I surmise that this has something to do with session timeout so I added an additional line in my web.config file specifying the maximum timeout. Please advise me if I'm on the right track.
Are there additional settings I need to apply in my IIS server to make the operation successful? Otherwise, are there anything I am missing? If you have experienced this before, kindly inform me what to do.
Thank you so much,
Ralph
This might be due to lot of proxy opened before. So I suggest you to delete Service.Reference.Config along with web service reference and add the service reference again and see whether it solves your problem.
Adding on to the previous answer, you may try setting up the execution time out on the proxy class , Refer this discussion
And you service call is performing a long running task you may prefer to have a lengthy time out for any webservice call by setting the timeout in proxy class as said before.
We have a web application where we are using global.asax for url rewriting. We use a compiled version of the site on the live server.
As a part of modification request, we had to add some custom native AJAX code where javascript would call a webservice to update the content of the page. For being able to call the webservice with extension .asmx, we modified the url rewriting code to handle asmx requests seperately.
this arrangement works fine on the local machine, but when we publish the site and deploy it on the live server, the new code doesnt seem to get included. It still skips the condition to check the ".asmx" extension, and throws a page not found exception considering the webservice name as a page name.
We have tried looking all over and googled for such things as well.. but no avail..
any pointers on what might be going wrong.. ?
Assuming your URL rewriting is good (isn't that normally implemented as a HttpModule?) I'd check to make sure that there's an ISAPI mapping in IIS on production that sends .asmx requests to ASP.NET.
If you think your changes to the global.asax haven't been rejitted then you can always stop the application pool, go find your web applications compiled bits in c:\windows\microsoft.net\framework[version]\temporary asp.net files... and delete the jitted version. I've seen ASP.NET miss when it comes to Jitting changes before.
I'd also consider running http fiddler (IE) or tamper data (FireFox extension) on one of the pages that makes calls to the web service. It will tell you exactly how the page is calling the web service and you can validate that the called URL is correct.
There is machine.config file where you can add HttpModules. I also think that you can do that through web.config.
One reason I can think of is that in the Web.config, you might have configured the routing module in the system.web section but not in system.webServer (or at least forgot something in there).
I the similar problem before and the solution was to remove the module & add it again in the system.webServer section of the Web.config like this:
<system.webServer>
<modules>
<remove name="UrlRoutingModule" />
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, e="RoleManager" type="System.Web.Security.RoleManagerModule"/>
</modules>
</system.webServer>
It might be a different module or handler but the idea is basically the same. It's important to "remove" the module first.