This bug follows bug 161893 Comment 3 in which I mention that when honoring the codebase attribute of the object element, the default plugin also passes a GET query string which is the MIME type of the what was used in the object element. Here's an example: Suppose I have an object tag like this: <object id="bleah" type="application/x-shockwave-flash" width="50" heigh="55" codebase="http://elwood.mcom.com/arun/xpi/Flash/flashplayer.xpi"> .... Here's what happens when the codebase attribute is honored: GET /arun/plugins/xpi/Flash/flashplayer.xpi?application/x-shockwave-flash HTTP/1.1 Host: elwood.mcom.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020802 Accept: text/xml,application/xml,application/xhtml Actual Behavior : Notice the query string is sent also. Expected Behavior : Should we also send the query string? We increase the likelihood of confusing server(s), tho' most servers ignore it.
I think this is the right behavior, codebase url could point to cgi script which will recognize mimetype and serve an appropriate plugin
codebase URL *could* point to a CGI script? Hmmm.. It also *could* point to a static XPI file. Since we don't know what codebase *could* point to, should we make assumptions? Basically, can someone tell me whether we violate HTTP spec. by sending query string along with a request for static resource? If *not* and if servers won't get confused, we should do nothing (and stick with this behavior). If yes, we should stop sending the query string. Maybe I'll also CC darin
arun: since there's no way to know if an URL corresponds to a static resource, there is no way to know if it's valid to add a query string to the URL :-/ doing nothing is probably the right thing to do... but really you'd have to consult the spec for <object> tags.
Per HTML 4.01: codebase = uri [CT] This attribute specifies the base path used to resolve relative URIs specified by the classid, data, and archive attributes. When absent, its default value is the base URI of the current document. The question here seems to be predicated on an incorrect application of the CODEBASE attribute. I think it is a bug to use CODEBASE to refer to an XPI file at all. I think you want to use ARCHIVE for this purpose.
Braden is correct, codebase should be used to set the base reference for the content of data, classid, or archive attribute. Good idea Braden about using archive, that could be an excellent solution to the xpi issue. But, to answer the question about appending the query string, if you look at form submissions, the query string is passed along with the URL when method=get is used. So I am not really sure why this would be an issue in regard to the object usage. Especially since the get method is being used.
Following comments assume this gets changed to use ARCHIVE instead of CODEBASE... As I understand it, Mozilla is actually morphing the URI by appending a query when it sends it to the server. In general, I don't think that is a good idea to send the server a URI that is different from what the page author specified. Perhaps I've misunderstood what's going on here?
Braden is correct from spec. point of view about 'codebase' vs.'archive', but we're doing what IE is doing here (where codebase points to signed CAB file for IE). True, doesn't make it right, but it gives us usage parity. Now on to the url-mangling issue: beppe: [getting an XPI] and [form submission] aren't the same thing. Form submission passes name-value pairs to a back-end program (e.g. CGI, etc.) that's expecting it, and so the 'GET' resource URL is constructed with a "?" and the query string. But this is merely a simple GET for a static resource (XPI) and doesn't need a query string. We make assumptions about a back-end that *could* exist to accept a query string, but *may not be in place* to do so. Remember, form submission is a "special case" of GET. What we're talking about is a classic GET without name-value pairs. braden: yes, your understanding of the issue relevant to this bug (spec. issues notwithstanding) is 100% correct.
Exactly what does that "usage parity" buy? IE doesn't support .xpi's anyway, so what's the point? Mozilla should follow the HTML spec. You don't know that you have an XPI until you've sent the request to the server, so there is no way for Mozilla to anticipate that it should munge the URI.
Braden, It "buys us" a way of using an attribute of 'object' element to download "missing software" in a way that was already used by another browser (IE for signed CAB files for ActiveX). True, IE doesn't support XPI, we don't support signed CAB. But both use codebase to download missing software. This is the way it works currently for 'codebase' in object element in Mozilla. Whether to use 'archive' as a better way should be subject of other bug.
For reference, folks: http://www.w3.org/TR/html401/struct/objects.html#h-13.3 If anyone's thinking of using archive instead of codebase, I don't think that's the right attribute either. According to the spec, classid specifies "the location of an object's implementation", and is a single URI. Archive is a URI-list, which from the wording seems like it's meant to point to additional information the plugin might need (perhaps for preloading boilerplate content, or additional modules?). If a change were made I'd submit that classid be the URI for the XPI, and codebase be used to either specify the base URI for that xpi, or be a URI that points to a web page that allows the user to manually choose and install a plugin. In fact, a browser could use this URI if it were unable to automatically install the XPI (or whatever resource classid specified), providing a good fallback case for browsers that don't support XPI or for platforms that don't have any plug-ins available.
Peter: Arun's right that the issue of correctly supporting CODEBASE warrants its own bug report. Please direct further discussion of that to bug 162993.
Arun: you missed my point -- a get method type of exchange to the server is permitted to contain an append, as indicated by the separator (?). When the string is received by the server it gets filtered (normally) through STDIN. The server from that point will extract the correct data and drop the rest. So, the appended string is not an issue.
beppe: The server isn't going just to drop the query string; that's important information for use in resolving the resource. In fact, the URI provided by the user may already have a query string. Consider a server that uses parameters in the query string to resolve the correct XPI to send to the client. Doesn't this bug affect the integrity of the query string in such a situation?
right: the logic is, if it is needed it is used, if it isn't it is ignored -- that was all I was trying to convey. So, if a query is sent and it is not needed, it should not interfer with anything.
beppe: I don't think that's guaranteed. http://elwood.mcom.com/arun/xpi/Flash/flashplayer.xpi and http://elwood.mcom.com/arun/xpi/Flash/flashplayer.xpi?application/x-shockwave-flash are two different URIs. The specs permit them to refer to different resources, and a server would be operating within the specs if it served different resources for each. If it is impossible for Mozilla to send the first URI when a user specifies it, that is a bug.
I was working on the premise that the server does not honor the string past the separator, in that case both strings are the same. In the second example, the server would only serve a different object if the string past the separator is processed along. In any event, I think we are saying the same thing, just from different perspectives.
> I was working on the premise that the server does not honor the string past the > separator, ... I don't understand the basis for that assumption. It is not possible to predict what the server will (or will not) do with the query string.
I talked to darin, barrowma, serge, peterl, doron, and av about this in today's plugins meeting. So it seems like I've worried too much about this :-) and used cycles. As braden says, we're not correct, but after talking to barrowma, it seems *most* server software will ignore the Query String, e.g. if you submit a request of the sort [resource]?[queryString] and if the server understands resource but NOT queryString, it will discard queryString. May we never get bitten in a real life scenario where this assumption causes trouble! We're safe, but we're still not absolutely correct. I'm really not convinced that we should send query string when trying to honor codebase. Let this fester, I guess...
There is an open question here that does not seem to be considered in the above comment: what happens if the URI in the page already has a query string on it?
--->WONTFIX based on comment #3 and comment #18 We no longer look for XPIs on CODEBASE of OBJECT tag. We now look in a PLUGINURL PARAM tag if you run with the fix in bug 167601.
Okay. But there are two (very separate) unanswered questions here: 1. Why *not* use ARCHIVE for this? A downloadable archive containing an implementation is *exactly* what it's for. At the very least, I think ARCHIVE should be supported in addition to the PLUGINURL PARAM. But probably instead of: if ARCHIVE is supported for this, what is the case for supporting PLUGINURL as well? 2. How does using PLUGINURL resolve the issue here? The issue is that having the user agent append a query attribute-valur pair to a URI stands to conflict with an attribute used by a Web site. We probably need another bug opened for 1. If 2 is not resolved, this bug should be reopened.
that's fine, we can keep this bug open about appending values to the query string, if one exists we can't use ARCHIVE because it conflicts with Java's use to point to a JAR
How could it conflict? Can you give an example of when you'd need to refer to both a JAR and an .xpi?
Updating summary. Here are the open issues: * What happens if the URI a site uses to refer to a plug-in implementation already includes a query part? If it replaces an existing query part, this is a serious bug. * In general, having the browser append a query string could conceivably cause the Web site to return a resource different from the objective one. (Because the browser really isn't requesting the same resource as was given in the Web page.) In practice, a failure of this nature appears to be uncommon.
The JAR points to where the applet's code is located. The XPI points to where you can download the plugin -- in this case, Java. So, they can conflict if one may want to use ARCHIVE to point to where to get the applet's files and use a PLUGINURL PARAM to point to where to download the required Java plugin if it's not installed.
The ARCHIVE discussion is straying from the main issues in this bug report. I've filed bug 186085 for discussion of that issue.
We don't support codebase download of .xpi files (that I know of anyway) so this is no longer relevant.