I'm supporting a legacy application on ColdFusion 7, and the pages are full of painful amounts of whitespace that I'd like to gzip away.
I know I can:
manually compress everything in an index type file (reference)
enable it in the web.xml (which I don't have access to)
But can I just throw the right < cfheader > or something akin to a .htaccess that triggers gzipping on this directory?
There are two ways to implement compression. At the web server level (apache 1.3 with mod_gzip or mod_deflate, IIS_6, IIS_7) or the application server level (coldfusion via a servlet filter).
I'm afraid those are the only options available to you for compression.
Otherwise you'll be looking at one or more of these:
enabling whitespace suppression via
cf administrator.
using <cfsetting
enablecfoutputonly="true"/> where
possible.
wrapping code with
<cfprocessingdirective
suppressWhiteSpace="yes"></cfprocessingdirective>
wrapping code with <cfsilent></cfsilent>
The only time I've seen CF handle GZIP itself, IIRC, is when using the internal (not for production) web server. I've always seen compression handled at the webserver (IIS or Apache) level.
If there is specific code that is dumping large amounts of whitespace, there are a number of options for dealing with it. Several are roughed out in an article by Ray Camden.
Personally, I don't worry about whitespace much unless it's really bad. I turn off output in CFCs (if something should be displayed, I return it), and I use CFSilent blocks around code blocks that shouldn't display output anyway.
Related
I've been tasked with creating a deployable version of a ColdFusion web app to be installed on a clients server. I'm trying to find a way to give them a compiled version of our code, and my first inclination was to use the CFCompile utility that I found here. However, after running CFCompile, most of the code in the CFM files is still readable. The only thing that appears to be obfuscated at all is the actual ColdFusion code - all of the SQL Queries are still perfectly readable. (Example in the screenshot below)
The HTML and JavaScript are also still readable in the compiled code, but that doesn't matter as those can be seen in a web browser anyways.
Is there another way to distribute my source code in a format that is completely unreadable to the user? I'm guessing that for whatever method I choose, there will be some way of decompiling the code. That's not an issue, I just need to find a way to make it more difficult than opening the file and seeing the queries.
Hostek has a pretty good write up on the subject over on their site - How to Encrypt or Compile ColdFusion Files.
Basically, from that article:
Using cfcompile.bat
The cfcompile.bat utility will compile all .cfm and .cfc files within a given directory into Java bytecode. This has the effect of making your source code unreadable, and it also prevents ColdFusion from having to compile your ColdFusion files on first use which provides a small performance enhancement.
More details about using cfcompile.bat can be found in ColdFusion's Documentation
Using cfencode.exe
The cfencode.exe utility will apply basic encryption to a specific file or directory. If used to encrypt a directory, it will apply encryption to ALL files in the directory which can break any JS, CSS, images, or other non-ColdFusion files.
They do also include this note at the bottom:
Note: Encrypting your site files with cfencode does not guarantee absolute security of your source code, but it does add a layer of obfuscation to help prevent unauthorized individuals from viewing the source.
The article goes on to give basic instructions on how to use each.
Adobe has this note on their site regarding cfencode:
Note: You can also use the cfencode utility, located in the cf_root/bin directory, to obscure ColdFusion pages that you distribute. Although this technique cannot prevent persistent hackers from determining the contents of your pages, it does prevent inspection of the pages. The cfencode utility is not available on OS X.
I would also add that it will be trivial for anyone familiar with ColdFusion to decode anything encoded with this utility because they also provide the decoder.
Looking at the docs, all the logging paths specified for console-capture and requestlog are relative to jetty.base, normally in $jetty.base/logs . That's ok for many purposes but, I really want logs to go into /var/logs/jetty , just like a lot of other processes would do. I've tried setting this in console-capture as /var/log/jetty, but that just tries to save log files in $jetty.base/var/log/jetty, which isn't what I need.
Is there some way to do this? I'm looking for the simplest possible approaches to saving logs. This is the last thing I need to do before my Jetty installation is fully in production. Overall it's been great. This is all with Jetty 9, latest release, on Ubuntu.
Start by not using console-capture.
You have progressed beyond the limited scope of console-capture with your requirement.
You'll want a formal logging framework, pick one, like "logback" (which the Jetty devs recommend), or java.util.logging, or log4j.
Use one of the logging-* modules to setup Jetty's server classpath to start using that logging library.
Now configure that logging library (example: if you are using "logback", the file ${jetty.base}/resources/logback.xml is what you configure)
Finally, configure your access logging to use slf4j.
Boom, all of your logging is now going to your logging library of choice, and it's configuration can be used to slice / dice / roll over / filter / etc the logging in any way you want.
You can have it split into different logging output files, combine them into one, roll on different rules (size, number of lines, duration, time, etc).
Definitely made some progress on this. For some reason, console redirect was taking the absolute path correctly while the request logger was not. For that, I made my configuration relative: ../../../var/log/jetty
This seems like a clunky way to do it but it does seem to work. I'm still getting a failure on startup but weirdly enough it's running fine and I don't see exceptions so I need to figure that out now.
I am trying to use Coldfusion CFPRINT to print UPS labels to a network printer. The starting labels (png files) are great and I can print them locally to the zebra printer and they print and work wonderfully. The barcodes produced by CFPRINT however are of such poor quality that a barcode scanner cannot read them. My research shows that Coldfusion uses the jpedal java library which resizes the images to 72 dpi - which is just not crisp enough for a scanner.
I read about using a jpedal setting: org.jpedal.upscale=2 but I have no clue as to where you would utilize this.
Any suggestions on how to fix this CFPRINT resolution issue using Coldfusion?
(Just to add a bit more detail to the comments)
That is a JVM argument. There are several ways to apply it:
Add the setting to your jvm.config file manually. Backup the file first. Then add -Dorg.jpedal.upscale=2 to the end of the java.args section. Save the changes and restart the CF Server. Do not skip the backup step! Errors in the jvm.config file can prevent the server from starting. So it is important to have a good copy you can restore if needed.
Open the CF Administrator and select Server Settings > Java and JVM > JVM Arguments. Add -Dorg.jpedal.upscale=2 to the end of the arguments. Save the settings and restart the CF server.
Again, I would strongly recommend making a backup of the jvm.config file first. As #Mark noted in the comments, some versions of CF have been known to mangle the jvm.config file, which could prevent the server from starting. But as long as you have a good backup, simply restore it and you are good to go.
IIRC, you could also set the property at runtime, via code. However, timing will be more of a factor. Their API states system properties must be set before accessing JPedal. The docs are not clear on exactly what that means. However, the implication is the system property is only read once, so if you set it too late, it will have no affect.
// untested
sys = createObject("java", "java.lang.System");
prop = sys.getProperties();
prop.setProperty("org.jpedal.upscale", "2");
sys.setProperties(prop);
Side note, I was not familiar with that setting, but a quick search turned up the CF8 Update 1 Release Notes which mention this setting "improves sharpness, but it also doubles the image size" and also increases memory. Just something to keep in mind.
We have a collection of VB.NET / IIS web services on some of our servers, and they have web.config files in the websites' root directories that they're already reading configurations from. There is a new configuration that needed to be added that will immediately be quite a bit longer than the others, and it'll only stand to grow. It's essentially a comma-separated value, and I'm wanting to keep it specifically in a configuration file of some sort.
At first I started doing this with a text file, but there was a problem with that. The text file's contents could change while web service threads and processes are running, so they would need to essentially re-read the file every time they needed to access its values. I thought about using some sort of caching, but unless the web services are completely restarted each time the file is updated, caching would block updates to the file from being used immediately. But reading from a text file each time is slow...
Then came the idea of putting that value in web.config, along with the other configurations the services are already using. When web.config is altered, the changes are able to be cached in the code, on top of coming into play immediately. However web.config is, well, web.config, and it's not a totally trivialized text file that is simply read out of in the code. IIS treats web.config in a special manner.
I'm tempted to think any negative consequences of putting a comma-separated value in web.config would be outweighed, in comparison to storing them in a text file (or a database, which probably can't be used for this anyway), but I guess I better ask.
What are the implications of storing a possibly lengthy, comma-separated value in web.config, instead of in its own little text file? Is either file a particularly good or bad idea? To me, it seems like web.config would be easy to get along with without having to re-read the file over and over, but there's certainly more to it than the common user is aware. Thanks!
I recommend using the Application Cache for this:
http://msdn.microsoft.com/en-us/library/vstudio/6hbbsfk6(v=vs.100).aspx
In our Windows 8 application, we are using the IXMLHTTPRequest2 method to stream files over HTTP, files whose size can reach gigabytes. This all works perfectly, except for the fact that internally, WinRT has a caching system which stores all that is streamed over the call to IXMLHTTPRequest2 in the temporary internet cache. As we stream more and more files, the cache is never emptied and it just starts taking more and more space on disk, until the disk is full.
Optimally, we would like to disable this caching functionality entirely. Another option we could live with would be that the cached files would be removed after a short while (although we'd like to avoid having to browse the temporary internet cache and removing files manually).
We've tried adding the "Expires: 0" header to the server response, as well as disabling the caching directly inside IE (we thought this might have an influence on the call to IXMLHTTPRequest2), but to no avail.
Anyone has any thoughts on this?
I realize this question is similar to another one posted here, however, our problem has more to do with the space that is taken by the cache rather than by the "freshness" of the files.
EDIT:
We have also found this post on the MSDN forums, where, according to a MSFT Moderator, "The system will also periodically cleans up the cache so you will not have to worry about running out of disk space", but that is not the case in our scenario.
According to this post on the MSDN forums, this isn't possible and is a known limitation with WinRT.
Sometimes the only answer is bad news. :-[
As ildjarn noted, this seems to be unavoidable on Windows 8. But it looks like there might be a way to fix this for clients running Windows 8.1.
I haven't tried it myself, but I just noticed that there is now "IXMLHTTPRequest3" which extends "IXMLHTTPRequest2" with some new features:
http://msdn.microsoft.com/en-us/library/windows/desktop/dn376398%28v=vs.85%29.aspx
The relevant feature is:
XHR_PROP_NO_CACHE – Suppresses cache reads and writes for the HTTP request.
That sounds promising.