Last Comment Bug 279729 - Notify user agent of xforms "capabilities"
: Notify user agent of xforms "capabilities"
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Stephen Pride
:
Mentors:
http://www.mozilla.org/projects/xforms/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-25 02:57 PST by Allan Beaufour
Modified: 2016-07-15 14:46 PDT (History)
12 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Adds xforms/1.0 to UA string (5.68 KB, patch)
2005-01-26 08:52 PST, Olli Pettay [:smaug]
no flags Details | Diff | Splinter Review
alternate approach for adding to the ua string (2.47 KB, patch)
2005-01-26 15:29 PST, Brian Ryner (not reading)
no flags Details | Diff | Splinter Review

Description Allan Beaufour 2005-01-25 02:57:30 PST
cite doronr:
> The right way to do this is by adding our string to the
> general.useragent.vendorComment preference.  For example, the activex
> plugin adds "ax" to it.  As xpis can't add preferences, xforms code
> probably has to check on startup if our string is included in the pref and
> possibly update it to the latest version, or append it to the preference.

I do not have a clue about how to do this... anybody want to look at it?
Comment 1 Allan Beaufour 2005-01-25 02:58:56 PST
The idea is to have something like "xforms/1.00", so a server-side processor can
detect whether the browser has support for XForms.
Comment 2 Darin Fisher 2005-01-25 14:16:14 PST
Extending the MozillaComment section of the UA string may be the only acceptable
change to the UA string.  See:
http://www.mozilla.org/build/revised-user-agent-strings.html
(NOTE: I'm not sure if this is the most up-to-date doc on mozilla UA strings.)

Of course, it would be nice to avoid expanding the UserAgent string.  I suppose
there is not a mime type that could be mentioned in the HTTP/1.1 Accept header :(

Does the w3c have any proposal to handle this problem?  If not, then perhaps the
w3c should be queried.
Comment 3 David Baron :dbaron: ⌚️UTC-10 2005-01-25 14:19:34 PST
This really shouldn't go in the User-Agent header.  It belongs in the Accept header.

And yes, http://www.mozilla.org/build/revised-user-agent-strings.html is the
most current doc.
Comment 4 Darin Fisher 2005-01-25 15:04:13 PST
I spoke with TV Raman briefly about this, and he didn't know of any standardized
solution to this problem.  He suggested working with the other folks developing
XForms useragents to come up with a reasonable defacto standard.
Comment 5 Brian Ryner (not reading) 2005-01-25 15:22:24 PST
It seems like we'd really like a way to advertise all of the XML namespaces that
we recognize, since as darin said, all XML documents will have the same MIME type.
Comment 6 David Baron :dbaron: ⌚️UTC-10 2005-01-25 15:47:48 PST
Something like an "Accept-XMLNS" HTTP header would be useful.  (I had an IRC
discussion with darin about this.)

It should have the capability to advertise versions and profiles as well.  Any
specification of such a header should probably define such version/profile
strings for important preexisting specifications (XHTML, SVG, XForms), leaving
it to later specifications to fill in their own.
Comment 7 Allan Beaufour 2005-01-26 05:36:33 PST
(In reply to comment #6)
> Something like an "Accept-XMLNS" HTTP header would be useful.  (I had an IRC
> discussion with darin about this.)
> 
> It should have the capability to advertise versions and profiles as well.  Any
> specification of such a header should probably define such version/profile
> strings for important preexisting specifications (XHTML, SVG, XForms), leaving
> it to later specifications to fill in their own.

If by profiles, you mean something like "combination of xhtml/1.1 and
xforms/1.0", and has an idea on how to define them, I'm the happy dude :)

I suppose this will not make it to the beta, so if we could add a comment to the
user-agent string until it is done, it would make my camp happy.
Comment 8 Olli Pettay [:smaug] 2005-01-26 08:52:30 PST
Created attachment 172461 [details] [diff] [review]
Adds xforms/1.0 to UA string

With this one the UA string looks like this:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b; xforms/1.0) Gecko/20050122

IE + FormsPlayer (+ MathPlayer) seems to have pretty similar UA string:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; formsPlayer 1.1; MathPlayer
2.0)
Comment 9 timeless 2005-01-26 14:46:54 PST
the problem w/ adding things to the useragent is that people will expect them to
be there. imo it is better to get this right than do the wrong thing early and
pay for it forever.
Comment 10 Brian Ryner (not reading) 2005-01-26 15:29:32 PST
Created attachment 172503 [details] [diff] [review]
alternate approach for adding to the ua string
Comment 11 Darin Fisher 2005-01-26 18:27:08 PST
vendorComment is not additive, so if any other extension tries to modify that
preference, then you will be "fighting" with it to see who gets to set the
vendorComment :-(
Comment 12 Darin Fisher 2005-01-26 18:55:41 PST
doh! i meant productComment... same thing applies to it.  maybe we should
support some sort of additive API for it.
Comment 13 David Baron :dbaron: ⌚️UTC-10 2005-01-26 20:47:01 PST
I think this does not belong in the user-agent string.
Comment 14 Brendan Eich [:brendan] 2005-01-27 16:22:43 PST
So wouldn't it be better to expose an API for Gecko extensions to add to the
Accept: header, and use a made-up XForms MIME type?

It's hard to believe that there isn't a de-facto, if not de-jure, type for
XForms.  application/x-xforms?  I see Hixie using
application/x-xforms-actions+xml in
http://www.hixie.ch/specs/xbl/XBL2-source.html (which you may have to visit by
going to its parent dir, then clicking on XBL2-source.html -- or read the Google
cache, lol).

Anyway, the UA is not for content negotiation, and the Accept header is not for
negotiating every little standard, but XForms and SVG are big, new, and optional
enough to justify some Accept: header bloat.

/be
Comment 15 aaronr 2005-01-27 21:20:37 PST
Well, there is the hasFeature method off of the DOMImplementation interface
(http://www.w3.org/TR/xforms/index-all.html#expr-hasfeature).  But again, that
would be more for a sniffer approach.  Plus, we haven't implemented that feature
in our XForms extension yet as that would be a core change to Mozilla in
nsGenericElement::InternalIsSupported -> 
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.cpp#1130

unless there is some way to extend the values provided here for extensions that
I don't know about.
Comment 16 timeless 2005-01-27 21:47:04 PST
if there isn't, then we need one.
Comment 17 Allan Beaufour 2005-09-15 05:08:22 PDT
Here's the section in the CDF draft:
http://www.w3.org/2004/CDF/Group/specs/CDR/wp1/wicd.xml#media-type-argument

I've been told that the CDF group leans towards solution 3 or 4, which is:
application/cdf+xml  ; profile=[profile ID]
or
applications/xml ; profile=[profile ID]

Anybody have some thoughts/comments on this?

(I'm way too tired and jetlagged or anything right now :( )
Comment 18 Allan Beaufour 2005-11-10 01:04:19 PST
We could add "XForms/1.0" to the user agent string using this:
http://www.mozilla.org/build/revised-user-agent-strings.html#implementation
Comment 19 aaronr 2005-11-10 09:08:35 PST
(In reply to comment #18)
> We could add "XForms/1.0" to the user agent string using this:
> http://www.mozilla.org/build/revised-user-agent-strings.html#implementation
> 

Do we want to take into consideration that we might not be the only XForms extension ever available for Mozilla?  We can also say, 'screw the other guy', too :=)
Comment 20 jhp (no longer active) 2005-11-10 09:25:39 PST
(In reply to comment #18)
The problem with this approach is that it doesn't specify which host language is supported for using XForms.  If the server sees "XForms/1.0" in the useragent string, does that mean that XForms is supported in XHTML?  What about SVG, or any other host language?  The server can assume, but it's not explicitly specified in the useragent string.  I think the only corrent way to do this is using the CDF spec (comment #17).  But I have no idea when that spec will be finished.
Comment 21 Allan Beaufour 2005-11-11 06:58:09 PST
(In reply to comment #20)
> (In reply to comment #18)
> The problem with this approach is that it doesn't specify which host language
> is supported for using XForms.  If the server sees "XForms/1.0" in the
> useragent string, does that mean that XForms is supported in XHTML?  What about
> SVG, or any other host language?  The server can assume, but it's not
> explicitly specified in the useragent string.  I think the only corrent way to
> do this is using the CDF spec (comment #17).  But I have no idea when that spec
> will be finished.
> 

I'm aware of CDF, I wrote that comment myself :) But 1) yes, when will it ever be finished, and 2) for 99% of the cases people want xforms+xhtml. I would still like the CDF approach, but there might be an advantage in adding the string still. And including the extension version makes it easy to dertermine what we support.
Comment 22 Allan Beaufour 2005-11-11 06:59:07 PST
(In reply to comment #19)
> (In reply to comment #18)
> > We could add "XForms/1.0" to the user agent string using this:
> > http://www.mozilla.org/build/revised-user-agent-strings.html#implementation
> > 
> 
> Do we want to take into consideration that we might not be the only XForms
> extension ever available for Mozilla?  We can also say, 'screw the other guy',
> too :=)

:) "MozillaXForms/0.3"
Comment 23 Doron Rosenberg (IBM) 2006-01-31 11:54:12 PST
Comment on attachment 172503 [details] [diff] [review]
alternate approach for adding to the ua string

What you could do is:

#filter substitution

pref("general.useragent.extra.xforms", "XForms/@PACKAGE_VERSION@");

I tried to get it working before finding this patch and it couldn't figure out package_version.  Maybe someone else has better luck :)
Comment 24 Olli Pettay [:smaug] 2013-11-28 08:23:00 PST
xforms is obsolete.

Note You need to log in before you can comment on or make changes to this bug.