Showing posts with label Cocoa. Show all posts
Showing posts with label Cocoa. Show all posts

Wednesday, June 02, 2010

Fixing -[NSMutableURLRequest setValue:forHTTPHeaderField:]

UPDATE

This problem is fixed as of Mac OS X 10.8.3+ and iOS 5.1+. I have no idea when it was actually fixed since radar sucks so much.

The problem

From NSMutableURLRequest setValue:forHTTPHeaderField: documentation:
In keeping with the HTTP RFC, HTTP header field names are case-insensitive.

I see three problems with this.
  1. Assuming all HTTP implementations are RFC compliant is foolish to say the least.
  2. Enforcing case-insensitivity is nonsense.
  3. This bit of documentation is accurate, the case of header fields is actually changed.
Trying this
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://www.example.com"]];
[request setValue:@"MyValue" forHTTPHeaderField:@"MyField"];
NSLog(@"result: %@", [request allHTTPHeaderFields]);
outputs
    result: {
Myfield = MyValue;
}
Notice how the 'F' of MyField was lowercased, that sucks! If the HTTP server you are trying to communicate with is case-sensitive, you are screwed. I filed radar #8029516, which is a duplicate of radar #3131623, which means there is almost no chance to have this fixed anytime soon.

When this happens, you should contact the server administrator asking for a case-insensitive implementation. But in the meantime, if you badly need to preserve the case of your headers, read on.

The investigation

First, let's fire otx to disassemble the Foundation framework in order to have a look at setValue:forHTTPHeaderField: implementation. I strongly suggest you to use otx version from subversion trunk, as it is better at resolving symbols in tail call optimizations (fixed in r553).

Excerpt from otx 0.16b:
   +18  [...]  movl     %eax,0x08(%ebp)
+21 [...] leave
+22 [...] jmpl 0x002c52bb

Excerpt from otx trunk:
   +18  [...]  movl     %eax,0x08(%ebp)
+21 [...] leave
+22 [...] jmpl 0x002c52bb _CFURLRequestSetHTTPHeaderFieldValue

Much better, isn't it?

So let's go through the function calls of setValue:forHTTPHeaderField:. With a basic static analysis of the Foundation and CFNetwork disassemblies, we can draw the following call path:
-[NSMutableURLRequest(NSMutableHTTPURLRequest) setValue:forHTTPHeaderField:]
CFURLRequestSetHTTPHeaderFieldValue()
URLRequest::setHTTPHeaderFieldValue()
HTTPRequest::setHeaderFieldValue()
CFHTTPMessageSetHeaderFieldValue()
HTTPMessage::setHeaderFieldValue()
_CFCapitalizeHeader()

_CFCapitalizeHeader looks like a very good candidate for being the bastard changing the case of our headers. A quick search reveals the source code of CFNetwork that was open source long time ago. Although the open source implementation does not exactly match what we see in the disassembly (it is now using toupper instead of ch + 'A' - 'a' for example), we are now absolutely sure that _CFCapitalizeHeader is the function responsible for messing with our headers.

Now, let's check is if there is a path that will not call _CFCapitalizeHeader and if we can somehow influence the condition that would avoid the call to _CFCapitalizeHeader. This is quickly checked, especially if you enabled the Separate logical blocks option of otx (-b option for cli).
HTTPMessage::setHeaderFieldValue(__CFString const*, __CFString const*)
+0 000515a4 55 pushl %ebp
+1 000515a5 89e5 movl %esp,%ebp
+3 000515a7 83ec28 subl $0x28,%esp
+6 000515aa 8b4508 movl 0x08(%ebp),%eax
+9 000515ad 8975f8 movl %esi,0xf8(%ebp)
+12 000515b0 8b7510 movl 0x10(%ebp),%esi
+15 000515b3 897dfc movl %edi,0xfc(%ebp)
+18 000515b6 8945f4 movl %eax,0xf4(%ebp)
+21 000515b9 8b450c movl 0x0c(%ebp),%eax
+24 000515bc 890424 movl %eax,(%esp)
+27 000515bf e88a26fbff calll __CFCapitalizeHeader
+32 000515c4 c744240cffffffff movl $0xffffffff,0x0c(%esp)
+40 000515cc 89742408 movl %esi,0x08(%esp)
+44 000515d0 89c7 movl %eax,%edi

We see that there is no path that avoid the call to _CFCapitalizeHeader. So we are left with the last resort solution: patching _CFCapitalizeHeader. With APE Lite, function patching is very easy. You first use APEFindSymbol() to find the address of a non-exported symbol (i.e. __CFCapitalizeHeader), then APEPatchCreate() to replace a function implementation with your own, while still keeping a reference to the original implementation. On iPhone OS, you can use APE Lite+arm (my implementation of the APE Lite API using MobileSubstrate).

The solution

NSMutableURLRequest+CaseSensitive is a category on NSMutableURLRequest that adds these three methods:
   - (void) setAllHTTPHeaderFields:(NSDictionary *)headerFields caseSensitive:(BOOL)caseSensitive;
- (void) setValue:(NSString *)value forHTTPHeaderField:(NSString *)field caseSensitive:(BOOL)caseSensitive;
- (void) addValue:(NSString *)value forHTTPHeaderField:(NSString *)field caseSensitive:(BOOL)caseSensitive;

Just pass caseSensitive:YES for preserving the case of your header fields.

Warning: you SHOULD NOT use this in production code. But hey, HTTP implementations SHOULD be case-insensitive ;-)

Saturday, November 07, 2009

CLAlert: NSAlert done right

From NSAlert documentation:

Currently, there is no visual difference between informational and warning alerts.

This was written at the time of Panther and this is still true in Snow Leopard. So why the hell is the setAlertStyle: method provided?

NSCriticalAlertStyle
This style causes the icon to be badged with a caution icon.

A caution icon, for a critical alert? That does not make sense!

Here are screenshots of the default behaviours with the three different alert styles:







The documentation is unfortunately right: there is no difference between the informational and the warning style. The critical style is indeed badged with a caution icon.

As you probably have guessed from the title of this post, I am not happy with this behavior, so I have written a class, CLAlert (MIT License) that displays alerts the way I think it should be done. I.e. a note icon for an informational alert, a caution icon for a warning alert and a stop icon for a critical alert as you can see on these screenshots.







CLAlert is a drop-in replacement for NSAlert. It requires at lest Mac OS X 10.5.

Thursday, November 05, 2009

Watch a large number of icons with Preview.app

Browsing .icns files in Preview.app can be painful. If you try to open all the icons of the CoreTypes bundle for example with the following command

open /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/*icns

you will get this view:


All the different sizes of the .icns are displayed, which makes it quite unpleasant to browse.

F-Script Anywhere to the rescue!

Install F-Script Anywhere into Preview, then do

  1. FSA → New F-Script Workspace

  2. Click the Browser For Target… button

  3. Click on one of the icons

  4. Choose the PVIKImageBrowserView object

  5. In the F-Script Object Browser, name the PVIKImageBrowserView browserView


Finally, in the F-Script interpreter, paste the following code:
groups := browserView layoutManager groups.
count := groups count.
0 to:count-1 do: [:i | browserView collapseGroup:(groups objectAtIndex:i)]


Tada, a nice browsable view of your icons!

Thursday, February 14, 2008

Upgrading a System Preference pane

The System Preferences application provides a convenient way to install a preference pane. Double-clicking the preference pane will prompt the user if he wants to install it for the current user only or for all users of the computer. Then System Preferences will copy the preference pane to ~/Library/PreferencePanes or /Library/PreferencePanes according to what was chosen asking for administrator password if necessary. Finally the preference pane will be loaded and presented to the user.

Now, let's see what happens when a preference pane is upgraded. Again, System Preferences is smart: it is able to detect if an older version of the same preference pane is installed and proposes to replace it [1]. Everything seems alright, but it is actually not! Things are more complicated if the preference pane to upgrade has already been loaded. That is, if the user already clicked the preference pane.

Indeed, preference panes are just a special kind of bundle which is loaded into System Preferences with the -(BOOL)[NSBundle load] method (cf. -(BOOL)[NSPrefPaneBundle instantiatePrefPaneObject] method of the PreferencePanes framework). The problem is that on Tiger, a NSBundle can not be unloaded. So when upgrading an opened preference pane, the old code is not unloaded and as a consequence the new code is not loaded. This is because System Preferences calls the -(BOOL)[NSBundle load] method which returns YES, meaning that the bundle was successfully loaded or that the code has already been loaded. In the case of an already opened preference pane, that's how the result of the load method should have been interpreted. Unfortunately, it is interpreted as if the bundle was successfully loaded and System Preferences thinks it has loaded the new bundle, but it has not.

This is very problematic because at this point, the resources (nib files, pictures etc.) of the new bundle have already been copied. So we have the old code which is accessing the new resources. I let you imagine the numerous problems this situation can cause. At best, exceptions will raise and your preference pane will be half working. At worst, your preference pane will simply crash.

So, how do we fix this problem?

First, the preference pane must detect itself when it's upgrading over an older already loaded version as System Preferences does not detect it [2]. This must be done as early as possible, i.e. at the very beginning of the - (id)initWithBundle:(NSBundle *) bundle method. It is possible to detect this situation with the help of the version of your NSPreferencePane subclass. See my detection snippet to understand how detection works.
Once this is detected, we must properly reload the new preference pane. This must be achieved by quitting System Preferences and relaunching System Preferences. This is the not that elegant solution to unload the old preference pane. The elegant solution would be to unload the bundle. This is left as an exercise to the Apple engineers for a future version of System Preferences.

Relaunching System Preferences and selecting the preference pane is quite tricky. A second executable must be responsible for relaunching the System Preferences application. Also, it is nicer for the user if the preference pane he just upgraded is automatically selected. Automatic selection of the pref pane is achieved through Apple Script. Please refer to my reload snippet for implementation details. Note that once you have compiled the reload executable, you have to place it inside the resources directory of your preference pane. Do not place it inside the executable directory (Contents/MacOS) if you do not want to see the reload application popping up in the Dock.

With this reload code in place, if the user ever happens to upgrade a preference pane while the older one was loaded, he will experience a System Preferences flicker as it will quit and reopen right away. While this might be surprising to him, this is still better than a half working preference pane or a crash.

If anything is unclear, just say it so in the comments and I will try to elaborate. If everything is clear, just pick up my code snippets and implement them in your preference pane as soon as possible ;-)



1. System Preferences uses the CFBundleGetVersionNumber function to retrieve the version numbers of the new and old bundles as an UInt32 in order to compare them. The documentation says If the bundle’s version number is a number, it is interpreted as the unsigned long integer format defined by the vers resource on Mac OS 9. What every developer understands is that if your Info.plist CFBundleVersion key represents a number (e.g. "519"), the value returned by CFBundleGetVersionNumber will be 519. This is not what actually happens. If you want CFBundleGetVersionNumber to return 519, you have to add an undocumented key in your Info.plist file: CFBundleNumericVersion. Make sure you define it as <integer>519</integer> and not <string>519</string>.↩

2. Note that on Leopard, this situation is actually detected and a dialog is presented to the user telling he must quit System Preferences and then open it again. Unfortunately, no automatic action is taken to circumvent this annoying behavior. System Preferences could restart itself or unload the bundle (this is possible since Leopard) but as of Mac OS X 10.5.2, none of this action is performed.↩

Monday, November 06, 2006

zip vs dmg

Most Cocoa developers use disk images (aka dmg) for distributing their softwares over the Internet. This is not really surprising as this is Apple's recommended practice for software distribution.

My gripe against this practice is simple: it's very slow. I did an experiment that I think is rather representative. I bundled a 1.9 MB application (Transmission) into both a zip file and a dmg file. I'm talking here about internet-enabled disk images, i.e. those which copy their content, unmount and go to trash automatically.

Here are the results of my experiment.

SizeTime
zip0.7 MB0.16 sec
dmg1.3 MB9.02 sec

Impressing, isn't it ? The size is almost twice bigger for the dmg although I used maximum compression (zlib level 9). That's bad (not all Mac users have a broadband connection) but what is worse is the time to prepare the disk image, verify the disk image, mount the disk image, clean up, check the download files, prepare the disk image, mount the disk image, copy the disk image, unmount the disk image and clean up. Yes, these are the ten operations required for an internet-enabled disk image to achieve the decompression! Zip decompression requires only two phases: decompressing the zip file and checking the downloaded files, thus it is 56 times faster.
Results may vary depending on application size and may be slightly different for a ten MB application but I can't see how a disk image could be either smaller or faster to decompress than a zip archive. If you know such an exemple, please post a comment about it.

Since Mac OS X 10.3, zip file compression and decompression is natively supported. Prior to Mac OS X 10.3, StuffIt Expander was bundled with Mac OS X. A convenient Create archive of "..." stands in the File menu of the Finder. It's simple and efficient, so why not using it ?

Some may argue that disk images are nice for drag & dropping the software into the Applications folder. While this is true, this is also very slow. When using a non internet-enabled disk image, users have to copy the application into the Applications folder which takes much more time than moving it. Moreover, they have to go to the desktop in order to unmount the disk image.

You have understood by now, I hate disk images and I hope more and more developers will use zip files in the future to distribute their softwares in order to save their users' precious time. ;-)

Finally, I suggest you have a look at these movies (no faking) showing how fast and how long it takes to decompress respectively a zip file and a dmg file.












Saturday, June 17, 2006

Relaunch your Cocoa application by itself

Here is a code snippet of a relaunch helper tool with instructions to use it.

keywords: self, restart, relaunch, cocoa, os x