I don't fully understand what is happening here, because executeRequest should return the same thing execute did, and I did not change anything in ProcessURL. I have the code here but cannot run it, and what happens to p0 escapes me...
Will look it up.

can likely fix favorites by adding a dispatch handler (which I'll do tonight), but I'm still curious about backward compatibility.  The fault condition with the current build, seems to hang the http engine by never providing the response.   
could a failed dispatch still issue the $callbackf?  otherwise, perhaps Slim::Web::HTTP::processURL should check the $request return and properly end the reponse?

I think the problem is here:

	if (defined($p[0])) {

		if (defined($params->{"player"}) && $params->{"player"} eq "*") {

			for my $client2 (Slim::Player::Client::clients()) {

				next if $client eq $client2;

				$client2->execute(\@p);
			}
		}

		Slim::Control::Request::executeRequest($client, \@p, \&generateHTTPResponse, \@callbackargs);

	} else {

		generateHTTPResponse(@callbackargs);
	}

if the request is not dispatchable, then given HTTP::processURL():
Slim::Control::Request::executeRequest($client, \@p, \&generateHTTPResponse, \@callbackargs);

means the generateHTTPResponse never gets called.  Favorites currently processes a custom command query via Favorites::Plugin::handleWebIndex. The page constantly shows the spiralling cursor becuase the page is expecting a response that does not come.

I think something similar was mentioned on the forum; it is a probem that ONLY happens when the url is using p0=..., since processURL traps $p[0] to determine that the url contains a 'command'

Well, the callback question is a philosophical one. Should callback be called if the request failed? Given callback is mainly used for webpages, I'd say yes, even though in their current implementation they won't have a clue the request DID fail (not that they had any before; I am just saying they probably should take advantage of the additional metadata the Request mechanism provides).

Implementing command handlers for favourites is good. That makes them available from the CLI (with the addition of something to return the favourites of course, which I can take care of in due course). My current "namespace" for plugins commands is "plugin.command", f.e. "favourites.move".

the problem in this case is that there is no request expected to be made.  the p0... params are intended for the handler (as is the case for a couple plugins mentioned in the dev forum: http://forums.slimdevices.com/showthread.php?t=D21527).  There is no telling how many will trip over this.

I dont think the http server should ever be blocked from sending a response, but I can see the problem of timing it so that it happens post-request.  

I've used "favorites" "move" and "favorites" "delete", since I could find no other examples.  easily changed, and I'll patch tonight.  I'll reword the summary later to better reflect the remaining issue.  I'm not sure how to solve that one.   I do wonder how many other visible symptoms arise from a failed request blocking the http response.

favorites plugin fixed at change 6602. remarking summary to reflect remaining issue.  needs direction from SD.

Changed 6624 to always call the callback

Also in 6625 slight rework on the favorite request handling code

Fixed, no?

ah yes, sorry.  missed your last note.