Should not append query string to URI used to retrieve plug-in




16 years ago
5 years ago


(Reporter: Arun Ranganathan, Assigned: Peter Lubczynski)



Firefox Tracking Flags

(Not tracked)




16 years ago
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=""> ....

Here's what happens when the codebase attribute is honored:

GET /arun/plugins/xpi/Flash/flashplayer.xpi?application/x-shockwave-flash
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b)
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.

Comment 1

16 years ago
I think this is the right behavior, codebase url could point to cgi script which
will recognize mimetype and serve an appropriate plugin

Comment 2

16 years ago
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

Comment 3

16 years ago
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.

Comment 4

16 years ago
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.

Comment 5

16 years ago
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.

Comment 6

16 years ago
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?

Comment 7

16 years ago
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.

Comment 8

16 years ago
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.

Comment 9

16 years ago

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.

Comment 10

16 years ago
For reference, folks:

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.

Comment 11

16 years ago
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.

Comment 12

16 years ago
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.

Comment 13

16 years ago
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?

Comment 14

16 years ago
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.

Comment 15

16 years ago
beppe: I don't think that's guaranteed.


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.

Comment 16

16 years ago
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.

Comment 17

16 years ago
> 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.

Comment 18

16 years ago
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...

Comment 19

16 years ago
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?

Comment 20

15 years ago
Assignee: beppe → peterl

Comment 21

15 years ago
--->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.
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Comment 22

15 years ago
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.

Comment 23

15 years ago
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 
Priority: -- → P5
Resolution: WONTFIX → ---
Summary: When honoring codebase attribute of object element, query string is also passed → default plugin should append value to query string in URL if one already exisits
Target Milestone: --- → mozilla1.4beta

Comment 24

15 years ago
How could it conflict? Can you give an example of when you'd need to refer to
both a JAR and an .xpi?

Comment 25

15 years ago
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.
Summary: default plugin should append value to query string in URL if one already exisits → Should not append query string to URI used to retrieve plug-in

Comment 26

15 years ago
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.

Comment 27

15 years ago
The ARCHIVE discussion is straying from the main issues in this bug report. I've
filed bug 186085 for discussion of that issue.
QA Contact: shrir → plugins

Comment 28

5 years ago
We don't support codebase download of .xpi files (that I know of anyway) so this is no longer relevant.
Last Resolved: 15 years ago5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.