- From: Francois Daoust <fd@w3.org>
- Date: Tue, 14 Oct 2008 17:43:26 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's discussion are available at:
http://www.w3.org/2008/10/14-bpwg-minutes.html
... and copied as text below.
Note there will be no "call" tomorrow, since we'll have a working
group's F2F on Monday and Tuesday.
Resolutions taken during the call:
- re. LC-2019, amend text on conversion between HEAD and GET to say that
other conversions are not allowed, and resolve partial to LC-2019
- ref LC-2034, we clarify that the scope of the document is limited to
GET, POST, HEAD requests and their responses and resolve "no"
- and we had a long talk on changing HTTP headers which I'll try to
summarize so that we may come to a conclusion next week.
Francois.
14 Oct 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0018.html
See also: [3]IRC log
[3] http://www.w3.org/2008/10/14-bpwg-irc
Attendees
Present
jo, SeanP, andrews, tomhume, Francois, rob, Bryan_Sullivan
Regrets
Chair
francois
Scribe
andrews
Contents
* [4]Topics
1. [5]HTTPS links re-writing
2. [6]LC-2019: POST/GET conversion
3. [7]LC-2034: Applicable HTTP methods (§4.1.1)
4. [8]LC-1997, LC-2006, LC-2014, LC-2046: Original HTTP
headers in X-Device-foo
* [9]Summary of Action Items
_________________________________________________________
Francois: Heiko is moving to another role so will not be joining
this call or future calls
HTTPS links re-writing
<francois> [10]FD's email to IETF TLS WG
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0014.html
<francois> "Since this is a man-in-the-middle attack, it would be
interesting to
<francois> know how browsers react in that case. It should be have
been made clear
<francois> to the user which site he connected to (www.proxy.com
instead of
<francois> www.amazon.com)."
Francois: Any view? I don't think mobile browsers indicate HTTPS
connections. Does anyone?
tomhume: Fixed web uses have address bar and security icon.
... this is missing in a mobile context
SeanP: Padlock security icon is on many mobile browsers but info
page must be viewed to display URL
Andrew: I disagree with the quotation about man-in-the-middle
attack. The user will have to be advised, so it's not an attack.
francois: Agrees that the use of "attack" is not quite correct but
point is that there is no indication to the user that the page is
intercepted
Andrew: there is visual indication on Vodafone pages of CT in
process
<Zakim> jo, you wanted to suggest that the wording we have proposed
should cover this so why don't we see how it flies
Francois: Happy with outcome of discussion last week on HTTP. Jo, do
you need more?
Jo: Have enough for editing guidelines. Will post proposed text on
list.
<jo> ACTION: Jo to redraft HTTPS section for discussion on list
[recorded in
[11]http://www.w3.org/2008/10/14-bpwg-minutes.html#action01]
<trackbot> Created ACTION-864 - Redraft HTTPS section for discussion
on list [on Jo Rabin - due 2008-10-21].
LC-2019: POST/GET conversion
<francois> [12]LC-2019 comment
[12]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2019
rob: comment was we should add note that posts should not be
translated into gets and vice versa
francois: this is in the HTTP standard. Do we need to restated this?
<Zakim> jo, you wanted to suggest that we elaborate the bit on
changing HEAD to GET to say that other conversions are not allowed
rob: Agreed. No strong feeling either way.
Jo: Let's say Head to Get is OK but other method changing must not
be done
<francois> PROPOSED RESOLUTION: re. LC-2019, amend text on
conversion between HEAD and GET to say that other conversions are
not allowed, and resolve partial to LC-2019
rob: Good point; let's do it.
<rob> +1
<jo> +1
<francois> +1
+1
<tomhume> +1
RESOLUTION: re. LC-2019, amend text on conversion between HEAD and
GET to say that other conversions are not allowed, and resolve
partial to LC-2019
LC-2034: Applicable HTTP methods (§4.1.1)
<francois> [13]LC-2034
[13]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2034
rob: Other exotic methods available. We are only concerned with Get,
Post and Head.
francois: Comment was that there could be new methods in the future
Brian: Heard that Connect method could be used for adaptation but a
Connect is a clear indication that user wants a secure connection to
the end server
Rob: A Connect should indicate "no adaptation - just tunnel"
,,, worth mentioning Connect in guide lines
<Zakim> jo, you wanted to say that as Rob puts it, the scope is
limited to HEAD GET and POST don't think we should mention CONNECT
Brian: Cannot have adaptation with Connect
<francois> "The scope of content that proxies transform is typically
limited to GET, POST and HEAD HTTP requests. Proxies should not
intervene in other HTTP methods."
<jo> PROPOSED RESOLUTION: ref LC-2034, we clarify that the scope of
the document is limited to GET, POST, HEAD requests and their
responses
<rob> +1
<francois> +1
<SeanP> +1
Andrew: But HTTPS links can e rewriten on HTTP pages. then CT proxy
becomes a content server.
<jo> PROPOSED RESOLUTION: ref LC-2034, we clarify that the scope of
the document is limited to GET, POST, HEAD requests and their
responses and resolve "no"
<francois> +1
+1
<tomhume> +1
Brian: There should be no use of Put method in CT
rob: Put is used for creating web sites rather than browsing
SeanP: Agree. Why did we put it in in the first place?
francois: It was included as a common HTTP method
<Zakim> tomhume, you wanted to point out that other applications
beyond browsers might be passed through transforming proxies
tomhume: Not a method used by browsers but there may be other
applications that use Put
<Zakim> jo, you wanted to point out to tom that the document says
that its scope is browsing only
jo: We are careful to limit discussion to the browsing context and
CT proxy should be sure that it is dealing with a browser. We can
not practically discuss every application.
RESOLUTION: ref LC-2034, we clarify that the scope of the document
is limited to GET, POST, HEAD requests and their responses and
resolve "no"
LC-1997, LC-2006, LC-2014, LC-2046: Original HTTP headers in
X-Device-foo
<francois> [14]LC-1997
[14]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/1997
<francois> [15]LC-2006
[15]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2006
<francois> [16]LC-2014
[16]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2014
francois: Tried to gather statistics on refused pages. One figure
from Brian - thanks.
<Zakim> rob, you wanted to summarise that IF headers are changed
THEN x-device- echoing is useful
rob: If we allow user agent header then echoing the header is a good
idea. Raises original question of whether we should rewrite headers.
<Zakim> jo, you wanted to say that LC-1997 suggests that since the
world is flat there is no need for spherical geometry
jo: LC-1997 is more of a political statement. Think that it is OK to
change the accept headers if a CT proxy. Separate question is
whether we should change the user-agent header.
<jo> PROPOSED RESOLUTION: ref LC-1997, 2006 and 2014, we say that if
a proxy changes headers then it must include a new X-Device- header,
it should not change headers "unnecessarily" and it should not
delete headers
<Zakim> jo, you wanted to answer bryan
Bryan: Reason to send original heads is to provide statistical
information to site owners to allow them to better serve their users
jo: Other reasons for the original headers. In some sites more than
the user-agent is used to decide what content to return.
SeanP: Novarra has been sending out x-device headers for sometime
and has heard that content providers use these to determine what
content to send out
<francois> [17]LC-2046 on HTTP headers deletion
[17]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2046
<jo> PROPOSED RESOLUTION: ref LC-1997, 2006 and 2014, 2046 we say
that if a proxy changes headers then it must include a new X-Device-
header, it should not change headers "unnecessarily" and it should
not delete headers
jo: Thinks that it is not necessary to change headers other than
accept and accept-charset - if one leaves aside for a moment the
question of User Agent (and UAProf)
Bryan: Knows that users use user-agent and UAProf
andrews: concerned that the proposed resolution is strong and a
major addition to existing guide lines. Needs careful consideration.
SeanP: Unclear what we are discussing
<Zakim> jo, you wanted to say that one person's unnecessary is
another person's essential
<francois> [18]section 4.1.5 on Alteration of HTTP Header Values
[18]
http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#sec-altering-header-values
jo: We need to focus on what other headers may or may not be removed
which could be used by sites in ways unpredicted by us.
<francois> Headers that may need to be changed:
<francois> - User-Agent
<francois> - UAProf
jo: Which headers need to be changed?
<francois> - Accept
<francois> - Accept-Charset
rob: No statistical evidence about sites that complain about wrong
browsers.
... Long tail sites are likely to complain.
Bryan: Echo point about the long tail. This is where CT realy adds
value.
andrews: do we need to change UAProf?
<francois> - Accept-Encoding
<francois> - Accept-Language
SeanP: Novarra changes accept-encoding and accept-language
<jo> [so it's basically Accept-*]
<jo> perhaps we should say "replace" rather than "change" when
referring to this
andrews: Does "change" include "remove"
rob: Headers are not removed.
<SeanP> I'll be there.
francois: Will prepare a detailed agenda for the face-to-face next
week
<tomhume> thanks all
Summary of Action Items
[NEW] ACTION: Jo to redraft HTTPS section for discussion on list
[recorded in
[19]http://www.w3.org/2008/10/14-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 14 October 2008 15:44:00 UTC