- From: Francois Daoust <fd@w3.org>
- Date: Mon, 02 Nov 2009 17:07:00 +0100
- To: Eduardo Casais <casays@yahoo.com>
- CC: public-bpwg-comments@w3.org
Eduardo Casais wrote: >> If you have evidence to support this, that >> would certainly help! > > I'll try to find specific references about > breaking AJAX again. Certain is that AJAX > content passed as application/xhtml+xml gets > modified by those CT-proxies that endeavour > to modify anything that passes through them > and looks remotely like a Web page. I agree but note this particular case would not be covered by your proposal. > In any case, better be safe than sorry: let us > prevent now the negative side-effects of eager > transcoders rather than having to revisit the > matter later when the damage is done. The > emergence of AJAX in the mobile world > requires a more resolute action than a vague > warning. > >> If the group accepts the thrust >> of your comment, could this perhaps be >> turned into a bullet point in 4.2.9 next to >> the one on the Internet Content Types >> associated with Mobile Content? > > That would lead to an underspecification. > > In the case of SOAP, we can definitely narrow > down the behaviour of proxies formally, based > on existing standards. Here, we can state: > > "A content transformation proxy MUST handle > HTTP requests from a terminal, and > corresponding responses to them, either > transparently or as a SOAP forwarding > intermediary, whenever the HTTP transaction > conveys a payload advertised as one of the > following MIME types: > > application/soap+xml > application/soap+fastinfoset > application/fastsoap > application/fastinfoset > > This in compliance with section 2.7.2, SOAP > Version 1.2 Part 1 - Messaging Framework > (Second Edition), W3C Recommendation 27 April > 2007." I'd be happy to take an action to get more background to section 2.7 in the SOAP document you refer to: http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#relaysoapmsg AFAICT, the section creates an analogy to HTTP proxies at the SOAP level, where forwarding and active intermediaries for SOAP messages roughly tranlate into transparent and non-transparent proxies for HTTP messages. Section 2.7.3 contains warnings about side-effects active intermediaries may have but does not forbid them. If the SOAP spec itself does not forbid active intermediaries at the SOAP level, why should we globally forbid non-transparent proxies operations on SOAP content? > As for AJAX communications, I do not see any > role for CT-proxies. How exactly are they > supposed to intervene in an application > specific client-server communication scheme > (i.e. what amounts to an application-specific > protocol)? I do not see a role either and don't remember people mentioning true use cases, but I do not think no immediate role and potential danger translate into "we must prevent". >> We had removed "application/xml" and "text/ >> xml" from past discussions because they may >> be used to serve XHTML content as explained >> in the introduction of XHTML Media Types: > > Those two types are recommended in the W3C > document about XMLHttpRequest, whereas they > are only possible but not recommended in the > XHTML media types document. > >> If we keep them in the list, one risk is to >> end up with a document that indirectly >> suggests to use "application/xml" or "text/ >> xml" for XHTML content to bypass proxies, >> whereas a more precise media type should be >> used whenever possible as recommended by >> the XHTML Media Types document. > > Well, > a) There is no indirect recommendation, since > this issue is clearly dealt with in section > H.1.4.1 of the CTG. If needed, the existing > statement may be reinforced. Good point. > b) That might be an issue for proxies -- but > they are the ones causing problems in the > first place and leading developers to attempt > bypassing them. > c) AJAX must avoid a double-jeopardy: if using > the recommended types (i.e. application/xml or > text/xml), then it is at the mercy of > unwanted transformations because those types > might be used for XHTML, even if this is not > recommended, even when AJAX does not actually > rely upon XHTML. > If AJAX uses XHTML and its recommended type, > then it might be viewed as browsing and get > transformed again. From this perspective, > there is absolutely no way out for an AJAX > application relying upon an XML type, except > emitting "no-transform" -- which I explained > is not always possible and is possibly more > difficult in the case of AJAX than for normal > browsing. > d) To give a quantitative perspective on the > matter: the MAMA study by Opera gives the > following results on MIME frequencies: > application/xml: 17 (0.00048%) > text/xml: 60 (0.0017%) > over a total of 3509180 transactions. It is > not like developers are using these types for > XHTML content like wild. > e) From your reply, I gather there is no issue > with application/json at all. This type is > unambiguously and exclusively used for AJAX, > and there is no rationale for altering content > of such type in transit. Yes, the whole thing makes sense. I still don't think we can put it under a MUST guideline though. Francois.
Received on Monday, 2 November 2009 16:07:35 UTC