Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content
Brought to you by:
alain-couthures
Menu
▾
▴
Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
|
From: Conal C. T. <con...@ve...> - 2011-07-22 13:08:13
|
Hi Philip
It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
Regards
Con
________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Friday, 22 July 2011 7:12 PM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
Conal,
Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
Regards
Philip
-----Original Message-----
From: Conal Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 7:08 AM
To: xsl...@li...
Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
I have been using XSLTForms recently, for editing XML metadata records.
In our project, we have a RESTful web service (based on a Fedora
repository) which uses HTTP Content Negotiation to publish different
representations of a resource (i.e. using the same HTTP URL, but in
response to different HTTP Accept headers).
Each resource may be represented as an XML metadata record or as an
XForm, depending on the content-type requested. If a browser sends a
request for an HTML page, we want to return an XForm embedded in HTML,
but if the browser doesn't want HTML, then we send the "raw" XML record.
If the browser accepts HTML, then it receives an XForm, and the XForm
itself then issues a request (to the same URL!) to retrieve the XML
instance. The problem is that XSLTForms doesn't specify an HTTP Accept
header, and the browser (Firefox 5 for example) sends its default Accept
header, which includes "text/html", etc. Hence the instance document
retrieved is not the "raw" XML representation, but rather an XForm (i.e.
the XForm has loaded itself as a model instance!)
I think it's a bug for XSLTForms to say that it accepts
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which
is the default Accept header in Firefox). It seems sensible to me to set
an Accept header listing "text/xml" and "application/xml", so that
XSLTForms can be used with services such as ours, which use content
negotiation.
I found I could fix the problem by explicitly setting the Accept header
in xsltforms.js, in two places (there is a case for Internet Explorer
and a case for other browsers). See below:
> if (window.XMLHttpRequest) {
> Core.openRequest = function(method, uri, async) {
> //
> netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
> var req = new XMLHttpRequest();
> try {
> req.open(method, Core.constructURI(uri), async);
> } catch (e) {
> try {
> req = new
> ActiveXObject("Msxml2.XMLHTTP.3.0");
> } catch (e) {
> try {
> req = new
> ActiveXObject("Msxml2.XMLHTTP");
> } catch (e) {
> throw new Error("This
> browser does not support XHRs(Ajax)! \n Cause: " + (e.message ||
> e.description || e) + " \n Enable Javascript or ActiveX controls (on
> IE) or lower security restrictions.");
> }
> }
> req.open(method, Core.constructURI(uri), async);
> }
> // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
> req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
> if (Core.isMozilla) {
> req.overrideMimeType("text/xml");
> }
> return req;
> };
> } else if (window.ActiveXObject) {
> Core.openRequest = function(method, uri, async) {
> try {
> req = new ActiveXObject("Msxml2.XMLHTTP.3.0");
> } catch (e) {
> try {
> req = new ActiveXObject("Msxml2.XMLHTTP");
> } catch (e) {
> throw new Error("This browser does not
> support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) +
> " \n Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
> }
> }
> req.open(method, Core.constructURI(uri), async);
> // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
> req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
> return req;
> };
> } else {
> throw new Error("This browser does not support XHRs(Ajax)! \n
> Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
> }
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297
------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
|
