Re: SVG12: Transfer-Encoding

Yves Lafon wrote:
> digging a bit (down to [1]), I think that the spec is correct as it 
> talks only about the data (entity in the HTTP world) 
> TE/Transfer-Encoding deals with the message level and is completely 
> hidden from a data presentation layer.

That part of the specification is talking about the server, not the 
presentation layer.  That is, per that spec any server that sends SVG 
data compressed with gzip must set Content-Encoding.  Even if the 
compression is a transfer-encoding in this case.  This does not seem to 
be the intent of the specification (or I certainly hope not!), but 
that's what it says.

> Also Transfer-Encoding is only hop-by-hop while Content-Encoding is 
> end-to end, meaning that a proxy can add or remove or keep (remove then 
> add) a Transfer-Encoding.

Indeed, but again we're talking about a single point in the message 
chain -- the "svg server".

> A bit like Content-Location which is almost mandatory when you want 
> to do serious editing, and that almost only a few UA care about...

This is way off topic, but, since you brought this up, there is a world 
of difference between not implementing and not caring.  I'm going to 
give you the benefit of the doubt and assume you don't know about what 
happened when we implemented Content-Location support in Gecko.  I 
suggest you read https://bugzilla.mozilla.org/show_bug.cgi?id=238654 and 
all its dependencies and then read bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=109553, but to summarize:

1)  Content-Location, when implemented per HTTP spec (as in Apache) 
interacts badly with content negotiation.
2)  Content-Location is implemented in a very broken way in a number of 
servers out on the web.  Servers from several different vendors.  Almost 
uniformly, the header is set to some random URI that points to a 
location behind a company firewall, which typically means that any 
relative URIs in the document suffer DNS resolution failures.  Worse 
yet, they typically take a very long time to suffer said failures, 
during which time the user might see nothing (relative <script> URIs 
block further parsing).

So we had to remove support for this header about 4 months after adding 
it...  We care very much about the functionality, and we hope that an 
update to the HTTP RFC will define a header that does what is needed 
here but does not suffer from the serious drawbacks that 
Content-Location has.  Once that happens, we will implement that header. 
  All the code to do it is in place; we just need to flip the switch.

-Boris

Received on Tuesday, 11 October 2005 17:30:49 UTC