How do I get ASP.Net CompositeScript to cache in the browser? - asp.net

I have been trying to improve the performance of a web page that references several separate JavaScript files. I found the new CompositeScript feature in .Net 3.5 SP1 that allows you to combine scripts at runtime through the ScriptManager and it works great to reduce the number of hits on our server at page load.
But the problem is that the combined script never caches on the client side. From everything I've read so far, it should do that automatically. I don't have anything set to prevent it from caching (other scripts we reference that could not be combined cache fine, as do the ScriptResource.axd files). I even added the following to explicitly enable caching in the web.config:
<system.web.extensions>
<scripting>
<scriptResourceHandler enableCompression="true" enableCaching="true"/>
</scripting>
</system.web.extensions>
But it doesn't seem to have an effect.
Has anyone seen this problem or have some suggestions on things I can try to fix it?

Is debug mode on anywhere? Make sure your webserver's Machine.Config has Retail="True"
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>

Related

Custom Sharepoint webservice requires web.config to be "touched" regularly

We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
At first everything works fine, but after a bit of time has passed the service will start to fail with:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
Interestingly enough
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
is still available, but a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
will fail as described.
We've found that "touching" C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\ web.config will bring the webservice back to life.
The asmx file lives at
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\ECan\MyECan_ComplianceWaterUsage.asmx
Any ideas of what might be going on here and how to resolve them?
Some extra detail:
App pool settings in case they're useful: http://i51.tinypic.com/x51qw.png
The following web.config settings are present in the root and sub directory hosting the asmx:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
We are calling the web service from javascript (jQuery). I've checked all the settings mentioned in this link and all match. I think calling from javascript may not be the culprit though as going directly to
[domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
with parameters supplied also fails with the same error - no javascript involved. Failing after a short period of time has passed, but works fine when web.config has just been "touched" again.
Thanks in advance for any help! Cheers, Gavin
I'm currently working on the same problem, and I think you barked the wrong tree.
The problem is, that in the ISAPI folder of SharePoint is a web.config with the following lines:
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
<remove name="HttpPostLocalhost"/>
<add name="Documentation"/>
</protocols>
</webServices>
The problem is, that the desired protocols POST and GET will be removed for the entire ISAPI folder and its subfolders. I also tried to reactivate the protocols via
<location path="[Path to my Web Service].asmx" allowOverride="false">
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</loaction>
in different places (machine.config, web.config of root folder, web.config app.config, ...), but it didn't last.
The only thing that worked, was, to change the "remove" items in the web.config of the ISAPI folder to "add" items.
But this has the nasty side effect, that the built-in web services, like "Lists.asmx" throw errors if you try to request their documentation pages...
If you can live with that, this would be your solution. I can't, so I still try to figure out a way to make my
<add name="protocol">
items persistent.
By the way: Also adding lockItem="true" to the <add/> items didn't do the trick...
Chris
It has been awhile since I have touched Sharepoint so this is a shot in the dark. If I remember correctly modifying anything in the web.config will restart the website in IIS. So what you may be seeing is IIS restarting the website that hosts the webservice putting it back into a good state.
Do you have the following in the web.config for the web application?
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
This is a strange problem and hard to diagnose due to the number of occcurances of the 12 hives web.config protocols issue which would appear to resolve 99% of the cases of this issue.
There is another issue called URL rewriting that will cause this
problem.
Some reverse proxy devices can modify the path of a request (the
portion of the URL that comes after the hostname and port number) in
such a way that a request sent by the user to
http://www.contoso.com/sharepoint/default.aspx, for example, is
forwarded to the Web server as
http://sharepoint.perimeter.example.com/default.aspx.
This is referred to as an asymmetrical path. Windows SharePoint
Services 3.0 does not support asymmetrical paths. The path of the URL
must be symmetrical between the public URL and the internal URL. In
the preceding example, this means that the "/sharepoint/default.aspx"
portion of the URL must not be modified by the reverse proxy device.
Even more depressing is that microsoft knows about this and actively refuses to support it.
Ref: URL Rewrite + SharePoint = No Support
Also : SharePoint, url rewriter, WebServices
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry. Thanks for all the suggestions though - it's been very much appreciated!

Severe Session issues ASP.NET

I have a kind of an ugly situation.
I have a big program that uses session to carry over data from one page to another in a CRM system build in ASP.NET 3.5 C#
The problem is that if you have two instance of this program open in the same browser and browse the same page, the sessions of course gets overridden.
As you can imagine, this is a huge issue and a huge liability for the system.
What is the right thing to do here? I use tons of AJAX, and need to pass objects from page to page, so url parameters is not really an option here.
Any suggestions?
What is your web.config sessionState configured? I think in your situation you can reduce the severity of your problem by configuring it as follows:
<configuration>
<system.web>
<sessionState mode="InProc" cookieless="true" timeout="20"/>
OR
<sessionState cookieless="true" regenerateExpiredSessionId="true" timeout="20" />
</system.web>
</configuration>
But the latter is going to mangle your URLs. You'll end up with ASP.NET inserting session IDs into your URLs, something like http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx. More about it here.

Disabling themes in a subdirectory with ASP.NET

This should be a simple one. I am using a program that has themes defined in its Web.config file. I want to turn these off for a subdirectory.
I copied Web.config into a subdirectory and tried removing the theme attribute from the pages element on Web.config but that didn't get me anywhere. I got a bunch of errors about elements that are apparently not allowed in non-root Web.config files so I removed all of those elements, but I am still getting the same error.
I tried adding EnableTheming="False" in the ASPX Page header, the thing that defines Language=C#, etc., but it didn't work either.
So if someone can tell me a tested, confirmed way to make this work, I would appreciate that. I am using .NET Framework 2.0 on Server 2003.
Got it with a very basic Web.config:
<?xml version="1.0"?>
<configuration>
<system.web>
<pages theme="" />
</system.web>
</configuration>

Enable all caches except asp net output cache

I have different urls that points to the same code
www.url1.com
www.url2.com
I need to use the cache, but if the asp net cache is enabled when someone access to www.url1.com next person accessing www.url2.com could get the previously cached data (www.url1.com)
I need to have ALL caches activated except this one.
You can disable ASP.Net output caching for the entire application by putting it in your web.config file.
<configuration>
<system.web>
<caching>
<outputCache enableOutputCache="false">
</outputCache>
</caching>
</system.web>
</configuration>
But unless you're actually putting anything in the cache in the first place, you don't have anything to worry about.

What is wrong with my MVC application?! (500 on Content and Scripts)

For anything under the Scripts or Content folders in my ASP.NET MVC application, I am getting the following error:
The page cannot be displayed because an internal server error has occurred
That's the response in its entirety (excepting the headers) - nothing else. I am hosting this on GoDaddy, and have not had problems with this application before. What did I do to screw this up?! Working on 4 hours of sleep isn't helping matters...
This would be appropriate here:
"It takes considerable knowledge just to realize the extent of your own ignorance."
-Thomas Sowell
So, when struggling to get a Flash-based, JavaScript-configured component to work in my web app, I added a staticContent node to my web.config, with a mimeMap node as a child:
<configuration>
...
<system.webServer>
...
<staticContent>
<mimeMap fileExtension=".mp4" mimeType="video/mpeg" />
</staticContent>
</system.webServer>
</configuration>
When I commented-out the entire staticContent node, everything worked just fine. I didn't know that adding a mimeMap here would cause all of the default mimeMaps (specified within the server's ApplicationHost.config) to be overridden, because that seems to be exactly what is going on...Then again, I am merely guessing - either way, not very easy to figure out.
Thank you to everyone that responded, I appreciate it!
In your web.config file, find the customErrors section and change mode to Off.
<customErrors mode="Off">
</customErrors>
Changing that will give you a more descriptive error.
I had the same issue when upgrading to a newer version of IIS, though with a different mime type. As you also surmised, I believe the new version must already have the type registered (or the host did it at the machine level). I solved it by putting "remove" before the "add" - all my content started showing up again. I would think this would prevent having to modify the config between dev and prod.
<staticContent>
<remove fileExtensions=".mp4" />
<mimeMap fileExtension=".mp4" mimeType="video/mp4" />
</staticContent>
This has been edited to replace video/mpeg with video/mp4. /mpeg still worked for me, but apparently mp4 is recommended.
Can you turn off Simple error messages?
Perhaps you could try putting
routes.IgnoreRoute("Scripts");
routes.IgnoreRoute("Content");
in your route register?
Also make sure that if you are using the built-in authentication, you have this bit in your web.config, though I think it isn't your problem:
<location path="public">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
Hmm, do you have any control of IIS on that hosting? Maybe they have a wildcard mapping interfering. That's happened to us before with site minder.
Download Phil Haack's Route Debugger, then try navigating to one of the Scripts. You might be catching them in your routes.

Resources