Special purpose clients are not likely to send more than one.

“Why would a client or server ever produce or consume wildcard content types? i.e. “text/*” or even “*/*”?”

IMO, wild card types apply to general purpose clients like browsers.

Aren’t the examples you gave (Googlebot, browsers) really special cases in that they are really just only reading content and not really interacting with the resource. In the browser’s case, its really just acting a dispatcher to a specific renderer plugin. I’m thinking more of the programmtic web, web applications (specifically Ajax + REST), or even BPM orchestrating a set of distributed services.

You think Googlebot was written that way? Or curl? Or browsers? No, they just support HTTP plus whatever data formats they need to get their job done. But they have no idea which resources will or won’t emit or consume this data at design time: it’s all discovered at runtime (save for the initial URI which is provided at configuration time).

I deployed a system a few years ago that exposed streaming data feeds with their own URIs, but the feeds could be expressed in two ways; HTML, for when somebody typed that URI into a browser, and a proprietary compressed binary format for automata interested in consuming that data. There’s no magic to it. That said, it’s long been recognized that the Accept header is a broken way to do negotiation, and that something like the Alternates response header is superior.

To answer your bullet questions, a client would use multiple Accept headers (or multiple types in a single header - same thing) to let the server know what formats it consumed. And the use of “text/*”, in practice, really just means that the client implements the fallback behaviour of all text/* types: that they can all be treated as text/plain (not particularly valuable, but that’s what it means at least). Using application/* would be meaningless. image/* is used when the client supports all the common image formats.

Mark.