- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 25 Nov 2008 01:47:41 +0000 (UTC)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTML WG <public-html@w3.org>
On Mon, 24 Nov 2008, Julian Reschke wrote:
> >
> > I don't understand why "ping" is special here. Surely this is what we
> > should do for everything that's new in HTML5? And if so, given that
> > pretty much the entire spec is new, why isn't HTML5 itself the
> > proposal?
>
> The spec may be new, but most of what it describes is not.
I beg to differ. I can't really think of anything in HTML4 that hasn't had
new requirements added in HTML5 (usually to remove ambiguities, define
processing in more detail, or define error handling).
> > Maybe you are not used to the strict application of the rule that we
> > must have two complete and bug-free implementations (with evidence
> > that the implementations are used) to keep the feature beyond CR. We
> > will be cutting big parts of the spec out; if ping="" doesn't prove
> > itself, it _will_ be cut, just like anything else.
>
> I personally would like things to be cut out earlier.
We cut things out sooner too. We've cut data templates, repetition
templates, multiple form association, etc, all in the last few months. As
far as I can tell the process is working.
> > > Do you have evidence of proxies not respecting Cache-Control:
> > > no-cache? And, if yes, would it affect the accuracy sufficiently?
> >
> > Proxying behaviour with GET is unpredictable enough to be a problem,
> > yes. I don't have any specifics I can point to in public, though. ...
>
> It would be helpful to have that information.
I agree that feedback should be public. However, I'm not going to ignore
private feedback.
> > > Furthermore: preventing fraud for click tracking is a hard problem.
> > > Using POST instead of GET won't help anyway with respect to this.
> >
> > It doesn't solve the problem, but it helps.
>
> How?
It makes it less likely that the link will be followed by people who don't
realise it's a ping. For example, a tool that scans an HTML file for URLs
and fetches them all to check for broken links would cause problems if we
used GET or HEAD, but would be fine if we had a different method.
> > I don't understand how the semantics differ from POST, so I'm really
> > the wrong person to write that document. I'm happy to use a method if
> > one is available. If you're not willing to do the work to set that up,
> > then your complaints about using the wrong method lose a lot of
> > credibility and really seem to appear more like obstructionism than
> > constructive criticism.
>
> On the other hand, I do not understand how the semantics differ from
> GET, so I'm not the right person to write it either.
I guess we'll stick to POST then.
> > > > Hardly an improvement, since it doesn't address any of the use
> > > > cases.
> > >
> > > There is no agreement that this use case is something HTML5 needs to
> > > solve.
> >
> > There is agreement, just not with you.
>
> Then please let the chairs test the level of agreement.
What have I done to prevent the chairs from testing agreement?
> > As far as I can tell, your objections to ping="" are as follows:
> >
> > * You don't agree that we should improve the user experience around
> > click-tracking. (Why not?)
>
> Nope.
>
> I don't agree that the solution as specified will be reliable enough so
> that it actually gets used; thus I'm opposed to including it into a
> standards project that is already complicated enough.
Ok.
I've received feedback from pretty big click-tracking groups saying they
plan to use it as is, so implementation feedback seems to support keeping
it in the draft.
Do you have any proposals for making it more reliable?
> I'm also concerned that UAs may implement the protocol part and neglect
> the UI part (which essentially is what almost happened in Firefox 3).
Since, as you pointed out, one of the reasons for disabling it in FF3 was
lack of UI, that seems like an unfounded concern.
> > * You think that using POST is a security problem (despite evidence
> > that it introduces no _new_ security problems), and would rather we
> > use GET or HEAD (implying that we should ignore the feedback that
> > these are not acceptable).
>
> I think that using POST *can* produce new security problems, while
> GET/HEAD wouldn't,
Could you describe the new security problem? So far all you have described
are problems that already exist with forms.
> and that GET/HEAD would just work fine.
I have received implementation feedback to the effect that they would not,
which is why we are not using them.
> I also believe that issuing an unsafe HTTP request in the context of
> page navigation is in conflict with the web architecture.
It appears that we are forced into this because there is no more
appropriate HTTP method. I would be happy to adjust the spec to use a more
appropriate method if one is created. In the meantime, since I do not
really think that this is in fact in conflict with the Web architecture,
> > * You think the Ping-To and Ping-From headers should be in the body
> > of the ping. (Why?)
>
> Because that's what the payload is for, and it avoids polluting the
> header registry with headers that are tied to a single specific use
> case.
That seems like a theoretical ("spec purity") concern. I've received
feedback from implementors to the effect that headers are more convenient
(e.g. they can be processed by Apache's log module more easily), so by our
"priority of constituencies" design principle, the right solution seems to
be to compromise on what we have now (a non-empty payload, but keeping the
data in the current headers).
> > Anything else?
>
> No, I think that's it.
So in summary:
* You don't agree that the solution as specified will be reliable enough
so that it actually gets used - other feedback claims otherwise.
* You are concerned that UAs may implement the protocol part and neglect
the UI part - implementators have specifically avoided doing this.
* You think that using POST *can* produce new security problems, while
GET/HEAD wouldn't - but haven't described these problems.
* You think that GET/HEAD would just work fine - other feedback claims
otherwise.
* You believe that issuing an unsafe HTTP request in the context of
page navigation is in conflict with the web architecture - but are not
willing to do the work to get a more suitable method that doesn't
conflict with other feedback we've received, and our design principles
say I must put practical implementation concerns above spec purity.
* You think the Ping-To and Ping-From headers should be in the body
of the ping because that's what the payload is for, and it avoids
polluting the header registry with headers that are tied to a single
specific use case - but other feedback has said that there are
implementation reasons to prefer headers, and our design principles
say I must put practical implementation concerns above spec purity.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 25 November 2008 01:48:19 UTC