I'm trying to download SWF files from a site the traditional way, but a few of the SWF files have been created dynamically through what I believe to be ASP.net 2.0.
Every attempt to D/Load results in the correct dimensions, height and width, but it just gives me empty white space.
Anyone have experience with this?
What do the SWF files do? Perhaps you have managed to download the SWF fine, but it has an internal check for some requirement? Are there 'flashvars' being passed into it or pulled from a QueryString perhaps?
If you view the site that has the SWF files working with something like Fiddler or HttpFox it might provide some insights?
Related
Whenever you reference something in your public or assets directory via link/script tags, are you only downloading what you reference?
For example, say I have an enormous amount of images in my public directory. Only images that are referenced on that particular page are downloaded, right?
Taking this further, say your stylesheet references a lot of images, and it serves every single page on the your website. So are all of those images downloaded?
You see, I'm probably lacking some fundamental background on this as I'm pretty new to web dev, and I don't have much experience with nginx/apache or the like. Please explain!
Yes, the browser has no idea, what files are located on the server. It only knows those paths that are referenced in HTML (via <link/>, <script/>, <img/>, <a/>, etc.).
You can also have a look at the so called access log of your web server or (better) your browser's developer tools (Firebug, Chrome DevTools) to investigate what happens under the hood.
I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?
I am relatively new in C# and ASP.NET MVC.
There is something unusual that happens and it could be a simple property setup...
I have a MVC Web app and a css file associated with it in my Content folder.
Now everytime I do some changes in the css file I don't see these changes when I run the app. It seems that whatever I do the app keeps on using the old file. I can see it when I do a View Source on the page.
I played a bit with the Copy to Output Directory property in Web Developer without any good results.
Am I really missing something here ?
Thanks
Either restart casini, the web server for asp.net, the icon down by the clock or try hitting F5 in the browser a bunch of times.
Try clearing the cache in your browser.
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.