Subject: [Uri-review] httpz:// scheme, aliases, protocol names

From: Mario Salzer <[email-masked]>
Date: Thu, 22 Jan 2004 17:45:43 +0100

Hey,

After fiddling with Accept-Encoding: headers and figuring out that
actually most Web servers don't support this, I found myself in
the need for a 'TCP deflate flag'. But as this is unlikely, I'd like
to write a RFC for "httpz://" now, which will be mostly an alias to
"http" but use zlib encoding on the whole socket connection. I think
this was especially useful for POST requests and for large amounts
of HTTP request headers (like with extensive RFC2295 usage).

Was it ok for something like "httpz://" to just point to the original
spec and say "see, this URL scheme works exactly the same" or is copy
& paste more appropriate for a RFC?

Second question, how relate URL schemes to protocol names (for assigned
port numbers)?  Initially "httpz://" would likely be implemented as
proxies besides clients and servers and also require a port number
different from 80.  However I'd like to have "httpz://" backwards
compatible in that servers have the additional work of distinguishing
zlib compressed connections from uncompressed ones, so that clients
could treat "httpz://" just as an alias to "http://" (and servers
detected this and just communicate on an uncompressed connection
stream).  Then someday "httpz://" was absoleted and a "httpz" proto
name should also point to port 80 per default.

Regards,
mario

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Thu, 22 Jan 2004 12:38:28 -0500

On 22 Jan 2004 at 17:45, Mario Salzer wrote:

> "http" but use zlib encoding on the whole socket connection.

I hardly think that the most useful workaround to the fact that most 
Web servers don't properly support the Accept-Encoding header (or is 
it the browsers that don't properly send it, or is it one of those 
chicken-or-the-egg issues where neither side has any incentive to try 
to support it as long as the other side doesn't either) is to come up 
with yet another URI scheme, which existing Web servers and browsers 
*definitely* don't yet support.

Since you'd have to do some lobbying to get the server and browser 
authors to add support for a "httpz" scheme, why not instead lobby 
them to support "Accept-Encoding", an existing standard, in a manner 
that does what you need it to do?

Anyway, this proposed scheme should properly be referred to as 
"httpz", not "httpz://"... the double slashes are a prefix for the 
hostname or authority portion of a URI, not a suffix to the scheme 
name, and the colon is a separator between the scheme and the rest of 
the URI, not a part of the scheme name itself.

-- 
Dan
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: Martin Duerst <[email-masked]>
Date: Thu, 22 Jan 2004 14:44:23 -0500

In addition, the problem with httpz: is that you would have to change
URIs if you decide to use compression, but you might want to change
this long after you have published some URIs. Therefore, Accept-Encoding,...
is the right thing to do. There is a lot of experience with this
kind of thing with respect to https:, which is generally considered
a bad thing.

Also, please note that Accept-Encoding is something the client
tells the server about the client's receiving capabilities.
I therefore don't exactly see how it's related to a POST
request, or to 'a lot of request headers'. Headers in HTTP
are never sent compressed (not even in MIME multipart).

Using gzip or so in a request entity (POST) is okay, but has
nothing to do with Accept-Encoding. The way to do this is to
simply send it with a header of
    Content-Encoding: gzip
The HTTP spec explicitly mentions such a case, as follows:
    If the content-coding of an entity in a request message is not
    acceptable to the origin server, the server SHOULD respond with a
    status code of 415 (Unsupported Media Type).
Because HTTP is a simple request-response protocol, the only
way to know whether a given content encoding is supported on
requests to a given server/URI is to try it. Making a server
actually accept it should not be too difficult; in Apache,
writing a module to do that should do the job.

Regards,    Martin.

---

From: Mario Salzer <[email-masked]>
Date: Fri, 23 Jan 2004 12:39:40 +0100

> kind of thing with respect to https:, which is generally considered

I found only a short discussion inside of RFC2817 regarding the "https"
scheme. I admit that "httpz" was similar to "https" in that it operates
between the application (http) and transport layers (tcp). Effectively
zlib packaging was best implemented as TCP flag (so it could be handled
transparently by OSs and all UNIXish protocols would benefit and no
doubled protocol names were required).

However "httpz" as my current workaround idea did not work simply inside
of http. What a httpz server would receive was:

  _?H@íåP@@¢swMQÐ/ÏH,I-K-ÒOËÌIUðH  Ð7Ô3äòÈ/.±R(//×KHÌ-ÈIÕKÎÏå
  -N-ÒuLOÍCÊe??TTé&?8úF@]?ÉÉcE@ñ?Ô?R}-.@OTm0]@@@

Which it then decoded back into this, before the real HTTP server kernel
proceeded:

  GET /whatever/file HTTP/1.1
  Host: www.example.com
  User-Agent: httpz-agent/0.1
  Accept: text/*

That's why it could also operate on 'a lot of request headers' like
the ones proposed by RFC2295 ("Accept: text/html; q=1.0, text/xhtml; q=1.0,
 text/xml; q=0.5, application/pdf; q=0.8, image/svg+xml; q=0.3,
 text/javascript; q=0.1, application/x-shockwave-flash; q=0.5,
 application/x-java-applet; q=0.5, audio/ogg; q=0.3, multipart/parallel,
 text/rtf; q=0.1, text/vnd.cunningham.wiki; q=1.0, x-world/x-vrml,
...").

> are never sent compressed (not even in MIME multipart).

Yes, and that's a thing a httpz protocol could work around. A client
could then assume, that a server supperted compression, if it detected
this by analyzing the URL (it's too late to detect, if the connection
was established).  And as this operated on the connection level, and
not on the HTTP/MIME level, it could as well compress the POST body
AND the headers.

Whatever, my question now is, if this would allow an additional "httpz"
scheme name, or if clients should be capable of detecting a different
protocol by anaylizing the URI. That is:

http://www.example.com:80/whatever/file   - a client would use HTTP
http://www.example.com:443/whatever/file  - a client would use HTTPS
http://www.example.com:323/whatever/file  - a client would use HTTPZ
http://www.example.com:77/whatever/file   - a client would use HTTP

And, btw, can the well-known protocol name be used instead of its
assinged well-known port number, like:

http://www.example.com:https/whatever/file

> writing a module to do that should do the job.

I doubt that any vendor will implement it in other means than replying with
the 415 error code (Apache doesn't even). I could sure write it and add it
to the Apache on my boxes, but that doesn't solve the problem of sending
large POST packets to another one.
A httpz proxy daemon was more likely to get widely adopted and would also
work, where Servers cannot compress transmitted content - just see the ietf
web server, which does no compression at all (and even if configured
correctly, still would refuse to use Content-Encoding for the large
generated lists, where this really mattered).

A "httpz" really operated as a different protocol, the question is, if a
new URI scheme is required, or if there was a more convinient way than
writing things like:
  <html><head><base href="http://example.com/">...
  <body>...
  <form action="httpz://example.com/cgi-bin/..." method="POST">... 

mario

---

From: Mark Baker <[email-masked]>
Date: Sat, 24 Jan 2004 15:40:00 -0500

Hello Mario,

>   -N-ÒuLOÍCÊe??TTé&?8úF@]?ÉÉcE@ñ?Ô?R}-.@OTm0]@@@

I agree that this is a valid case for a new URI scheme.  However, my
concern is that while (for https) securing the initial message to a
resource is a critical requirement in many cases - and therefore arguably
worth the bother of deploying a new URI scheme - I can't see the
bandwidth savings on that initial request as similarly critical.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Mario Salzer <[email-masked]>
Date: Tue, 27 Jan 2004 03:45:00 +0100

Hey Mark,

> bandwidth savings on that initial request as similarly critical.

I actually have a real application for it in mind, that is XML-RPC,
where it regularily happens, that there is a few hundreds KB of text
data in the request AND in the response. And I believe there are
much more applications that abuse HTTP simply as transport vehicle,
and where the lack of correctly implemented content-encoding really
hurts (not only for speed purposes).

Use within POST/upload forms in web pages may really be minimal, and
so adoption by browsers/clients may also not be that important and
the "httpz" thing then boiled down to just a protocol / port number.

Anyhow, I'll start this by writing a minimal httpz proxy daemon or
even better a libhttpz.so pre-loadable library, which simply
intercepted the socket API and could then be used to add support to
nearly all server daemons (not only Apache). If this then was used here
and there often enough I'll just come back to discuss on the separate
URL scheme idea again.
(Making this an offical scheme name would anyhow depend on its spread?)

mario

---

From: Mark Baker <[email-masked]>
Date: Mon, 26 Jan 2004 23:33:41 -0500

Hi again,

On Tue, Jan 27, 2004 at 03:45:00AM +0100, Mario Salzer wrote:
> data in the request AND in the response.

Ok, but as I understand it, those KBs are in the body, right?  So I'd
suggest that using Content-Encoding on the request and response would
give you about the same results as httpz (depending upon the 
compression scheme used, obviously).

httpz seems to just buy you header compression over the alternative,
so unless you've got lots(!) of headers, I don't think it's a
particularly compelling option, especially when one considers the
enormous cost of URI scheme deployment and the fact that
Content-Encoding support is pretty well deployed.  Sorry!

Cheers,

Mark.