- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sun, 08 Apr 2012 12:41:51 +0000
- To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
- cc: ietf-http-wg@w3.org
In message <3dfc2c17927267e41710084836183f71.squirrel@arekh.dyndns.org>, "Nicol
as Mailhot" writes:
>1. discoverability, to handle network guests (right now taken care of wpad+pac
>though a lot of clients do not handle those, [...]
I would have thought this was a job for DHCP ?
>3. a way to signal the web client a request is being processed (there is no
>way a multi-GB iso is going to pass through the anti-malware system
>instantaneously, and users will press retry if the download bar does not move
>after a few seconds)
That sounds like serious scope-creep to me.
>4. A way to inspect most of the client communication for malware. I say most
>because :
If the site policy is "everything gets inspected", the protocol must support
that, either by allowing inspection, or by preventing the communication.
It site administrators choose not to, because of sound use of
decretion/legally requiments etc, that is not a relevant factor in
the standardization.
>5. a way for distribution sites to signal a resource is duplicated on a CDN,
>and what the root resource is (systems like sourceforge are killing caching,
>every new request is redirected to a different distribution server)
Etags could almost do this, if there were a way to say blind the Host:
header ("Vary: -Host" ?)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 8 April 2012 12:42:19 UTC