Have to say I really don't understand how come this could happen:
I've done some code in html, css and a little bit of javascript, nothing fancy,
and just uploaded to two host servers, one to my commercial hosting, the other to uni server.
The funny thing is my commercial server renders exactly as what I can see on localhost, which is of course the expected result. However, the page rendering on uni server is a nightmare:
The CSS stylesheets, although are retrieved from server (verified using Firefox and checked http responses), do nothing to page elements as if there were not there...which I don't understand why?
There is nothing different in my code I believe, I've used two different FTP tools to transfer the code. The only different that I can tell are the server environments, particularly one is Apache 2.0+ and the uni Apache 1.3.3
But I reckon client-side code would not really depend on Apache server versions, would it?
Thanks for any suggestion in advance!
The server where it doesn't work is sending the CSS file back with the wrong MIME-type (text/plain instead of text/css). Recent browsers are liable to ignore CSS files that don't carry the correct MIME-type. So yes, it is an issue of server configuration (mod_mime for Apache).
Related
If you have limited server resources and expect a lot of traffic to a Flash site, is there a way of NOT having to serve Run-Time Shared libraries, but rely on Adobe to do this for you?
For example, if you want to make sure "framework_4.0.0.14159.swz" is always fetched from "fpdownload.adobe.com" and not from your own server, what modifications should be made to the config section:
<runtime-shared-library-path>
<path-element>/opt/flex4/frameworks/libs/framework.swc</path-element>
<rsl-url>http://fpdownload.adobe.com/pub/swz/flex/4.0.0.14159/framework_4.0.0.14159.swz</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
<rsl-url>framework_4.0.0.14159.swz</rsl-url>
<policy-file-url></policy-file-url>
</runtime-shared-library-path>
...
<static-link-runtime-shared-libraries>false</static-link-runtime-shared-libraries>
Also, is there any reason this might be a bad idea?
Please notice, I am using the command-line compiler, mxmlc.exe (not Flex Builder).
UPDATE:
I guess my issue is more about the errors I get at run-time than the above question. In fact, the reason Flash tries to download from my server to begin with is that the Adobe download fails (see error messages in my comment). I am therefore going to accept the below answer and, if I don’t succeed in solving the problem, I might open up another question.
from Using the framework RSLs:
Note: You can point to the SWZ files
that are hosted on the Adobe web site,
rather than deploy your own SWZ files
as RSLs. In this case, view the
default entries for the RSLs in the
flex-config.xml file to see how to
link to them.
You can, but you never should - adobe.com does go down sometimes, or the client maybe allowed access to your site and not Adobe's (because of a corporate firewall, for instance).
When I run the site using the normal debug feature of Visual Studio, a lot of images go broken and formatting seems messed up. However, when I deploy the site, it all seems fine.
What could be the reason? As long as it looks good deployed, is it safe to ignore the formatting issues that come up with using undeployed websites?
Note: I am using same browser for both deployed and undeployed website.
My guess would be image and CSS paths. Perhaps they are relative? Definitely need more information (code) to give you a solid answer.
EDIT: A good way to troubleshoot this would be to right click on the image while debugging and copy its address. Then right click on the image when deployed and copy its address. Compare the two addresses and you might spot something obvious like a path problem.
What are the exact paths of your deployed and undeployed web sites?
You probably have images and CSS files that are referenced using a path that only works on the undeployed web site.
Try loading the deployed web site while running Fiddler and checking which URLs generate errors.
How exactly are you referencing the images and CSS files in your ASP .Net source?
Reasons are addressed by Mayo - but to answer the other question:
No, it is absolutely not safe to ignore the issues unless you have a very clear understanding of why they arise at which point you may be able to choose to not worry about them (although I'd probably not be particularly happy to have to so do).
There are reasons why it may not be practical but pragmatically I require that we can pull a project from version control, build and run and it more or less should run pretty much as live (there are a few caveats about meeting requirements for installed stuff and any necessary config) - certainly I'd expect the appearence to be right.
I would guess that you have some errors in your image paths. Try checking the resulting HTML with for instance Firebug(which is awesome!) to see if the path is wrong.
Maybe like Mayo say, probably the path.
Are you using ~ before your path ... like ~/_images/myImage.jpg or _images/myImage.jpg.
Most of the time, it happens because the ASP.NET development server start your application as a website and you probably deploying on iis in a virtual directory (as an application). So path beginning with / will not react the same way.
As suggested by Cédric, you can start your url with ~ but only if you're using a server site control (like asp:image) or an img html tag with runat="server".
For CSS, javascript or any regular html, you must make sure that all your resources are relative to the page.
I3dx give a good suggestion using firebug to track the faulty url.
Hope it will help
I have a weird situation with my sharepoint css.
It is deployed as part of a .wsp solution and up until now everything has been fine.
The farm it deploys too has a couple of webfront ends and a single apps server and SQL box.
The symptom is that if I deploy the solution, then use a webbrowser to view the page it has no styles, and if I access the .css directly I see the first 100 or so bytes of the .css.
However if I go into sharepoint designer and look at the file it is looks fine, and if I check it out and publish it (customising the file but not actually changing anything in it) then the website works fine and the css downloads completely.
There is some fairly complex caching on the servers Disk based and object caches. as far as I can tell I have cleared these (and an issreset should clear them anyway... shouldn't it?)
I have used this tool to clear the blobcache from the whole farm http://blobcachefarmflush.codeplex.com/
The problem you're describing is one I've encountered before. Let me share what I know, what I suspect, and how I'd go about troubleshooting your scenario.
First off, it sounds like you suspect caching as a potential problem source. In the case of the MOSS publishing feature set, you really have three different cache mechanisms in operation: the object cache, the BLOB cache, and the page output cache. The only mechanism that should be in-play, assuming it's turned on with default settings, is the BLOB cache. Neither the object cache nor the page output cache should be touching stand-alone stylesheets like you have.
You've tried flushing the cache the flush using the farm-level BLOB cache flush feature, and that will instruct MOSS to dump all BLOB cache data. You can verify this by reviewing the file system to ensure that only the three .bin folders remain following a flush.
To your specific question regarding an IISRESET: no, and IISRESET actually won't clear the BLOB cache. The contents of the BLOB cache persist beyond the life of the application pool servicing the web application. You either need to use a feature to clear out the cache (as you have been), or perform a manual file delete. I don't recommend the latter unless you absolutely have no other course of action. If you do elect to go the manual route to try it, ensure that you shutdown the W3SVC service before deleting files out of the file system. If you don't, the actual file deletion process can get into a race condition with cache repopulation and lead to corruption. After you've deleted files with a stopped W3SVC, you can start the W3SVC back up again.
For more information on the internals of the BLOB cache and how it operates, I'll point you to a blog article of mine: http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/
To see if the BLOB cache is a factor in the behavior you're seeing, you can modify the web.config for your web application(s) and adjust the file pattern to remove CSS from the list of file types in the <BlobCache> element and then restart IIS (or at least recycle the app pool).
Another possibility, based on experience, is that you're seeing something other than BLOB cache abnormalities. The key observation for me comes in the form of you observing that a direct request for the CSS stylesheet returns only the first 100 bytes or so.
Do you, by any chance, have any intelligent network hardware (that is, intrusion detection hardware or anything that might be performing application/layer-7 filtering) between the WFE and you, the caller? Intrusion detection and IPS systems are the source of many of the types of problems you're seeing, and they're one of my first stops whenever I see "oddball" behavior like you're describing. In the case of one of my clients, I saw a problem meeting your description (CSS and JS files getting truncated) due to an intervening Juniper firewall with active IPS. Turning off IPS (to test) cleared things up immediately. After that, the networking team sought an update from Juniper to correct the issue to ensure that IPS could remain active.
Try turning off BLOB caching (or removing the CSS extension from the file pattern) to see if that makes a difference. If not, talk to your network team to see if something is happening to the response stream coming back to you. That's where I'd start; hopefully, one of those two things will do the trick for you.
Small side note: if you have a free moment and are up to it, I'd like to hear about your experience with the BlobCacheFarmFlush solution you pulled down from CodePlex. I authored it, and I'd love to hear your thoughts -- good or bad :-)
Sean (sean#sharepointinterface.com)
Obviously having whitespace in css, aspx and html pages is a great advantage at design time. But is there a way to (a tool that will) clear all the whitespace from all the files and possibly merge javascript and css files in a more optimal way.
I am using asp.net themes so there are quite a lot of separate css files that would be improved through some form of automated combining. I have seen a few http modules but that isn't quite what I want I just want to run something over the published project beofre sending it to the server.
EDIT: Compression at least in IIS is unfortunately not an option, we are currently running it on the same IIS server as a third party web based student management system. It doesn't like compression and the IIS options don't seem to be per application pool. I did apply asp.net compression but the bulk of my extra data seems to be the app_themes which I know would compress well I just don't want to have to manually go through compressing all the css separately.
An empirical study on the effect of removing white space from a not-untypical website (Drupal) showed minimal effects. (site also contains some links to non .net html white space removal tools)
I have gotten magical improvements in page size by aggressively managing viewstate size and using Blowery's http compression module.
Another strategy is to do minifiation (merging many css files into one). Telerik has such a component RadStyleSheetManager, it works only with style sheets embedded into assemblies.
There is another way
http://omari-o.blogspot.com/2009/09/aspnet-white-space-cleaning-with-no.html
I think one of the reasons that this was never included in .NET was because they expected you to turn on server compression in these scenarios. IMO I don't agree with this -- I think it's a shame that at least aspnet_compiler.exe can't do this optimization. It would be such a great performance boost on uncompressed connections. Anyway, you can enable compression on IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true
And it's even easier and more flexible in IIS7 to do so. I hope someone has a better solution than I!
4 guys from Rolla just published an article on a http module that removes white space. You would need IIS 7 in integrated mode to make it work for css (or possibly IIS6 with wildcard mappings)
It looks more like a proof of concept, but the code is free.
i found this:
http://msdn.microsoft.com/en-us/library/aa719805(VS.71).aspx
greets!
From an earlier post about trying to improve my sites performance I have been looking at HTTP compression. I have read about setting it up in IIS but it seems to be a global thing for all IIS application pools I may not be allowed to do this as there is another site running on it as well. I then saw some code to put in global.asax to achieve the same thing on a per website basis.
See Here http://www.stardeveloper.com/articles/display.html?article=2007110401&page=1]1
Is this as good as the setup in IIS? How dramatic is the effect? Any known issues?
If you move forward with this, I'd suggest implementing a HttpModule versus global.asax. The HttpModule allows you to disable compression with a config change versus rebuilding and allows you to monkey with your compression Assembly separate from your web app.
Rich Crane has a pretty nice 2.0 module here: http://www.codeplex.com/httpcompression/ if you want to get up and running fast.
The blowery project Steven Rogers mentioned is a HttpModule as well.
Otherwise, writing your own is pretty straightforward. A HttpModule gives you the same events as global.asax - BeginRequest, EndRequest, and finer grained events like PostReleaseRequestState and PreSendRequestHeaders which you may need to iron out all the wrinkles.
As far as IIS compression verus HttpModule, IIS is definitely easier since you don't have to fuss with yet another Assembly. I've used both methods with business apps and both perform about equally under load testing. If IIS is available, I'd say use it.
Between 60 and 80% compression for HTML, JS, CSS, and XML files is common with gzip. Keep in mind a lot of your payload may be images and multimedia objects which are much harder to compress.
http://blowery.org/httpcompress/
We've used this compression utility at my job for a while. Pretty good.
I think the Global.asax option will be a good if you are in a shared hosting environment for example, where you don't have access to IIS configuration.
IIS 6 provides basic compression support, but if you're already in IIS 7, it provides you great HTTP compression support, you can define which files get compressed based on their MIME type in your configuration files...
It achieves essentially the same thing as IIS compression - both end up sending the response with gzip compression. I've recently implemented this method, and it consistently reduces response size by 60% with no performance impact worth worrying about.
There are a few possible issues. Firstly, you need to be careful about output caching. You need to use a custom VaryBy to make sure that different versions are cached for requests with different Accept-Encoding headers. Otherwise, if the compressed version is cached then all users will receive it, whether or not their browser can accept it.
Secondly, GZipStream will sometimes truncate the last few characters from the response if you use Response.End or Response.Flush, because the stream isn't closed until too late. I'm not aware of any nice solution to this.
Finally, this will only compress your HTML. Any CSS or Javascript files will be served normally. You'd need to, for example, serve those files via a custom IHttpHandler to compress them.
There are issues with JavaScript and VBScript. The JavaScript problem has been confirmed in a comment by xxldaniel on a codinghorror article, and I had issues with VBScript (for M$ Office automation) using a JSON-like "Scripting.Dictionary" with "Microsoft.XMLHTTP" request.
You may try mod_gzip modules. It uses managed ZLib version and allows highly adjustable configuration. Syntax is compatible with the same named Apache module and even extended. So for example you could set different compression level for different mime types and so on.