On Mar 6, 2013, at 9:05 AM, Wendy Roome wrote: > Clearly you've been burned by middleboxes! I have as well, although not > since the 1997. > > But don't most of those problems come from middleboxes trying to "improve" > html -- simplify it, remove ads, reformat it, etc? Or compress images? And > don't those middleboxes base their transformations on the content type? > Since ALTO messages are new mime type, it's unlikely those boxes would > change them.
Its not just burned by middleboxes, but one of the few who really SEE lots of the middleboxes with Netalyzr and explicitly test them, since a lot of the tests are centered around finding middleboxes and making sure they actually work right. (In fact, the original reason I started writing Netalyzr was suspicion that my (now dropped) home ISP had a malfunctioning in-path cache.) > Also, I believe one of the reasons for switching to a more REST-ful > structure (around draft 8) was to make it easier for proxies to cache full > network and cost maps. OH F#)@#*( NO. Web caches are not that common, but when they are they are BROKEN half the time: caching data which should not be cached. Seriously, about 1/2 the in-path HTTP caches observed with Netalyzr cache data marked as "oh, please don't cache", or "OH FOR THE LOVE OF PETE DON'T CACHE THIS"! > And although I haven't personally been burned by this, I've been told some > middleboxes block port 443. Eg, to prevent employees from shopping when > they should be working. Anyone blocking 443 is "breaking the web", because there are a huge # of sites which have absolute business need but also require TLS for at least sign-on. A better solution for such businesses is to put in their own root certificate into browsers and use one of the SSL middleboxes, which are nicely commercially available for these cases. >> And once you mandate support for TLS, what reason is there to not always >> use it? > > Here's the reason. Suppose the protocol spec states that an ALTO server > *cannot* use unencrypted http. That's telling a potential ALTO service > provider, "You're too stupid to make the right choice. We know best." > > Yes, that is a very nasty way to put it. But that is the message that > requirement would send. Unencrypted HTTP needs to die anyway. But I can see the point of "FORCE TLS" might be a problem in a few cases. But MANDATING TLS support is essential for far more cases, and if you MANDATE TLS, it is the height of foolishness not to prefer TLS. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
