From ietf-http-wg-request@tux.w3.org Mon Nov 4 09:45:17 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA4Ej7B04726 for ; Mon, 4 Nov 2002 09:45:07 -0500 (EST) Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA07039 for ; Mon, 4 Nov 2002 09:45:02 -0500 Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127]) by hplb.hpl.hp.com (8.12.1/8.12.1/HP Labs Bristol relay) with ESMTP id gA4Einwx007864 for ; Mon, 4 Nov 2002 14:44:49 GMT Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id OAA03425 for ; Mon, 4 Nov 2002 14:44:48 GMT Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8]) by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA11704 for ; Mon, 4 Nov 2002 14:44:47 GMT Received: from sand.cybersurf.com ([209.197.145.195]) by hplb.hpl.hp.com (8.12.1/8.12.1/HP Labs Bristol relay) with ESMTP id gA4Eiawx007755 for ; Mon, 4 Nov 2002 14:44:38 GMT Received: from Rxhk (ham-uas-2-209197175186.3web.net [209.197.175.186]) by sand.cybersurf.com (8.12.5/8.12.5) with SMTP id gA4EmZHD003609 for ; Mon, 4 Nov 2002 07:48:36 -0700 Date: Mon, 4 Nov 2002 07:48:35 -0700 Message-Id: <200211041448.gA4EmZHD003609@sand.cybersurf.com> From: msabin To: http-wg@cuckoo.hpl.hp.com MIME-Version: 1.0 content-type: multipart/mixed; boundary="C8V13N82HP29p01Xdk15M46opdf02uL8X" X-MailScanner: Found to be infected X-MailScanner: Found to be clean X-Spam-Status: No, hits=2.5 required=5.0 tests=FROM_NAME_NO_SPACES,SUBJ_HAS_Q_MARK,UPPERCASE_25_50 version=2.31 X-Spam-Level: ** Subject: {VIRUS?} Compressed X-Archived-At: http://www.w3.org/mid/200211041448.gA4EmZHD003609@sand.cybersurf.com --C8V13N82HP29p01Xdk15M46opdf02uL8X Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Warning: This message ha= s had one or more attachments removed. Please read the "VirusWarning.txt" a= ttachment(s) for more information.

--C8V13N82HP29p01Xdk15M46opdf02uL8X Content-Type: text/plain; charset="us-ascii"; name="VirusWarning.txt" Content-Disposition: attachment; filename="VirusWarning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment ".pif" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Mon Nov 4 14:44:46 2002 the virus scanner said: >>> Virus 'W32/Klez-H' found in file ./gA4Eiawx007755/.pif Shortcuts to MS-Dos programs are very dangerous in email (.pif) Note to Help Desk: Look on hplb.hpl.hp.com in /var/spool/mailscanner/quaran= tine (message gA4Eiawx007755). --=20 Postmaster --C8V13N82HP29p01Xdk15M46opdf02uL8X Content-Type: application/octet-stream; name=login[1].htm Content-Transfer-Encoding: base64 Content-ID: PCEtLXdlYjEzMDA1LS0+CjxodG1sPgo8aGVhZD48dGl0bGU+WWFob28hIE1haWw8L3RpdGxl PjwvaGVhZD4KPGJvZHkgYWxpbms9IzAwMDBmZiB2bGluaz0jMDAwMGZmIGJnY29sb3I9I2Zm ZmZmZj4KPHNjcmlwdCBsYW5ndWFnZT0iamF2YXNjcmlwdCIgc3JjPSJodHRwOi8vdXMuaTEu eWltZy5jb20vdXMueWltZy5jb20vaS9tYy9tYy5qcyI+PC9zY3JpcHQ+CjxzY3JpcHQgbGFu Z3VhZ2U9IkphdmFTY3JpcHQiPgo8IS0tIApmdW5jdGlvbiBIZWxwKGRhTGluaykgewogICAg dmFyIGhlbHBXbmQ9d2luZG93Lm9wZW4oZGFMaW5rLCJoZWxwIiwid2lkdGg9NDAwLGhlaWdo dD01MDAsc2Nyb2xsYmFycz15ZXMsZGVwZW5kZW50PXllcyIpOwp9CmlmIChkb2N1bWVudC5j b29raWUuaW5kZXhPZigiZHBKcThBIikgPT0gLTEpIHsKICAgIHdpbmRvdy5vcGVuKCJodHRw Oi8vbWFpbC55YWhvby5jb20iLCAiX3RvcCIpOwp9Ci8vIC0tPgo8L3NjcmlwdD4KCgo8dGFi bGUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCBjZWxsc3BhY2luZz0wIHdpZHRoPTEwMCUgaGVp Z2h0PSI1MiIgPgo8dHI+Cjx0ZCBub3dyYXAgYWxpZ249bGVmdD4KPGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsLEhlbHZldGljYSIgPjxiPldlbGNvbWUgbmlra2lvZGFtZUB5YWhvby5jb208 L2I+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9mb250Pgo8L3RkPgo8dGQgbm93cmFwIGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCxIZWx2ZXRpY2EiID4KPGEgaHJlZj0iaHR0 cDovL3JkLnlhaG9vLmNvbS9tYWlsX3VzL3BpbW5hdi93ZWxjb21lLz9odHRwOi8vd3d3Lnlh aG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPllhaG9vITwvYT4gCiAKLSA8YSBocmVmPSJodHRw Oi8vcmQueWFob28uY29tL21haWxfdXMvcGltbmF2L3dlbGNvbWUvP2h0dHA6Ly9teS55YWhv by5jb20iIHRhcmdldD0iX2JsYW5rIj5NeSBZYWhvbyE8L2E+CiAKJm5ic3A7Jm5ic3A7Jm5i c3A7CjxhIGhyZWY9Ii95bS9PcHRpb25zP1lZPTUyNTA5Ij5PcHRpb25zPC9hPiAtIAo8YSBo cmVmPSIveW0vTG9nb3V0P1lZPTUyNTA5IiB0YXJnZXQ9Il90b3AiPlNpZ24gT3V0PC9hPiAt IAo8YSBocmVmPSJqYXZhc2NyaXB0OkhlbHAoJ2h0dHA6Ly9yZC55YWhvby5jb20vbWFpbF91 cy9oZWxwLz9odHRwOi8vaGVscC55YWhvby5jb20vaGVscC91cy9tYWlsL2NvbnRleHQvY29u dGV4dC0yMy5odG1sJykiPkhlbHA8L2E+CjwvZm9udD48L3RkPgo8L3RyPgo8dHIgaGVpZ2h0 PSIyIj48dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPTI+PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55 aW1nLmNvbS91cy55aW1nLmNvbS9pL3BpbS9saW5lLmdpZiIgaGVpZ2h0PTIgd2lkdGg9MTAw JT48L3RkPgo8L3RyPgo8dHIgaGVpZ2h0PSIyNSI+Cjx0ZD48dGFibGUgYm9yZGVyPTAgY2Vs bHBhZGRpbmc9MCBjZWxsc3BhY2luZz0wPjx0cj48dGQ+CjxzY3JpcHQgbGFuZ3VhZ2U9amF2 YXNjcmlwdD4NZnVuY3Rpb24gcG9wdXAoKSB7DXBvcHBlZFdpbmRvdyA9IHdpbmRvdy5vcGVu KCdodHRwOi8vcmQueWFob28uY29tL009MTc5ODQyLjE2ODU0NTkuMzIxNDc0NS4xMjg0NDc0 L0Q9bWFpbC9QPW0yMnZ2Y2FkMTEydjA1MDAvUz0xNTA1MDAwMTQ6UEIvQT05MDU0NTcvUj0w LypodHRwOi8vc2hvcC5zdG9yZS55YWhvby5jb20vY2dpLWJpbi9jbGluaz9jb21wYXEyK3No b3BwaW5nOmRtYWQvTT0xNzk4NDIuMTY4NTQ1OS4zMjE0NzQ1LjEyODQ0NzQvRD1tYWlsL1A9 bTIydnZjYWQxMTJ2MDUwMC9TPTE1MDUwMDAxNDpQQi9BPTkwNTQ1Ny9SPTEvMTAxNzY4MjUz NytodHRwOi8vdXMucm1pLnlhaG9vLmNvbS9ybWkvaHR0cDovL3d3dy5jb21wYXEuY29tL3Jt aS1mcmFtZWQtdXJsL2h0dHA6Ly93d3cuY29tcGFxLmNvbS95YWhvby9zaG9wcGluZy5odG1s JTNGYz15YWhvb19wb3dlcmVkYnklMjZuPVhfRV9CUl9YX3Bvd2VyZWRieV9YX1hfWCUyNnQ9 YWQlMjZyPXd3dy55YWhvby5jb20nLCJwb3BVcFdpbiIsInRvb2xiYXI9bm8sc2Nyb2xsYmFy cz1ub3MsbG9jYXRpb249bm8sd2lkdGg9NzAwLGhlaWdodD01MDAiKTsNfQ12YXIgcjA9Imh0 dHA6Ly9yZC55YWhvby5jb20vTT0xNzk4NDIuMTY4NTQ1OS4zMjE0NzQ1LjEyODQ0NzQvRD1t YWlsL1A9bTIydnZjYWQxMTJ2MDUwMC9TPTE1MDUwMDAxNDpQQi9BPTkwNTQ1Ny9SPTIvKiI7 DXZhciByZWQ9cjAuc3Vic3RyaW5nKDAscjAubGVuZ3RoLTMpOw12YXIgdXJsPSJqYXZhc2Ny aXB0OiBwb3B1cCgpIjsNdmFyIGltZz0iaHR0cDovL3VzLmExLnlpbWcuY29tL3VzLnlpbWcu Y29tL2EvMS0vZmxhc2gvY29tcGFxL3Bvd2VyYnlfMTAwOF83NngyNF90cmFucy5naWYiOw12 YXIgZmxhPSJodHRwOi8vdXMuYTEueWltZy5jb20vdXMueWltZy5jb20vYS8xLS9mbGFzaC9j b21wYXEvcHdyZGJ5Y3BxX21haWxfYW5pbTIuc3dmIjsNdmFyIHN0YXJ0cj0yOw12YXIgd2lk dGg9NzY7DXZhciBoZWlnaHQ9MjQ7DTwvc2NyaXB0Pg08c2NyaXB0IGxhbmd1YWdlPWphdmFz Y3JpcHQgc3JjPWh0dHA6Ly91cy5hMS55aW1nLmNvbS91cy55aW1nLmNvbS9pL3d3L2ZsYTVj LmpzPjwvc2NyaXB0Pg08bm9zY3JpcHQ+PGltZyBzcmM9Imh0dHA6Ly91cy5hMS55aW1nLmNv bS91cy55aW1nLmNvbS9hLzEtL2ZsYXNoL2NvbXBhcS9wb3dlcmJ5XzEwMDhfNzZ4MjRfdHJh bnMuZ2lmIiB3aWR0aD03NiBoZWlnaHQ9MjQgYm9yZGVyPTA+PC9ub3NjcmlwdD48L3RkPjwv dHI+PC90YWJsZT48L3RkPgo8dGQgdmFsaWduPW1pZGRsZSBub3dyYXAgYWxpZ249cmlnaHQg aGVpZ2h0PSIyNSI+Cjx0YWJsZSBib3JkZXI9MCBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5n PTA+Cjx0cj4KPHRkIHZhbGlnbj1taWRkbGU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsLEhl bHZldGljYSIgPgo8YSBocmVmPSIveW0vd2VsY29tZT9ZWT01MjUwOSI+PGltZyBzcmM9Imh0 dHA6Ly91cy5pMS55aW1nLmNvbS91cy55aW1nLmNvbS9pL3BpbS9tbHMyLmdpZiIgaGVpZ2h0 PTI0IHdpZHRoPTI0IGJvcmRlcj0wPjwvYT4KPC9mb250PjwvdGQ+Cjx0ZCBub3dyYXAgdmFs aWduPW1pZGRsZT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCxIZWx2ZXRpY2EiID4KPGEg aHJlZj0iL3ltL3dlbGNvbWU/WVk9NTI1MDkiPk1haWw8L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7 CjwvZm9udD48L3RkPgo8dGQgdmFsaWduPW1pZGRsZT48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwsSGVsdmV0aWNhIiA+CjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vbWFpbF91cy9w aW1uYXYvd2VsY29tZS8/aHR0cDovL2FkZHJlc3MueWFob28uY29tL3lhYi91cy8/WVk9NTI1 MDkiIHRhcmdldD0iX3RvcCI+PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55aW1nLmNvbS91cy55 aW1nLmNvbS9pL3BpbS9hZDIuZ2lmIiBoZWlnaHQ9MjQgd2lkdGg9MjQgYm9yZGVyPTA+PC9h Pgo8L2ZvbnQ+PC90ZD4KPHRkIG5vd3JhcCB2YWxpZ249bWlkZGxlPjxmb250IHNpemU9IjEi IGZhY2U9IkFyaWFsLEhlbHZldGljYSIgPgo8YSBocmVmPSJodHRwOi8vcmQueWFob28uY29t L21haWxfdXMvcGltbmF2L3dlbGNvbWUvP2h0dHA6Ly9hZGRyZXNzLnlhaG9vLmNvbS95YWIv dXMvP1lZPTUyNTA5IiB0YXJnZXQ9Il90b3AiPkFkZHJlc3NlczwvYT4mbmJzcDsmbmJzcDsm bmJzcDsKPC9mb250PjwvdGQ+Cjx0ZCB2YWxpZ249bWlkZGxlPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCxIZWx2ZXRpY2EiID4KPGEgaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9tYWls X3VzL3BpbW5hdi93ZWxjb21lLz9odHRwOi8vY2FsZW5kYXIueWFob28uY29tLz9ZWT01MjUw OSZhOT15bTpuYXYiIHRhcmdldD0iX3RvcCI+CjxpbWcgc3JjPSJodHRwOi8vdXMuaTEueWlt Zy5jb20vdXMueWltZy5jb20vaS9waW0vY2wyLmdpZiIgaGVpZ2h0PTI0IHdpZHRoPTI0IGJv cmRlcj0wPjwvYT4KPC9mb250PjwvdGQ+Cjx0ZCBub3dyYXAgdmFsaWduPW1pZGRsZT48Zm9u dCBzaXplPSIxIiBmYWNlPSJBcmlhbCxIZWx2ZXRpY2EiID4KPGEgaHJlZj0iaHR0cDovL3Jk LnlhaG9vLmNvbS9tYWlsX3VzL3BpbW5hdi93ZWxjb21lLz9odHRwOi8vY2FsZW5kYXIueWFo b28uY29tLz9ZWT01MjUwOSZhOT15bTpuYXYiIHRhcmdldD0iX3RvcCI+CkNhbGVuZGFyPC9h PiZuYnNwOyZuYnNwOyZuYnNwOwo8L2ZvbnQ+PC90ZD4KPHRkIHZhbGlnbj1taWRkbGU+PGZv bnQgc2l6ZT0xIGZhY2U9IkFyaWFsLEhlbHZldGljYSIgPgo8YSBocmVmPSJodHRwOi8vcmQu eWFob28uY29tL21haWxfdXMvcGltbmF2L3dlbGNvbWUvP2h0dHA6Ly9ub3RlcGFkLnlhaG9v LmNvbS8/WVk9NTI1MDkiIHRhcmdldD0iX3RvcCI+PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55 aW1nLmNvbS91cy55aW1nLmNvbS9pL3BpbS9ucDIuZ2lmIiBoZWlnaHQ9MjQgd2lkdGg9MjQg Ym9yZGVyPTA+PC9hPgo8L2ZvbnQ+PC90ZD4KPHRkIG5vd3JhcCB2YWxpZ249bWlkZGxlPjxm b250IHNpemU9IjEiIGZhY2U9IkFyaWFsLEhlbHZldGljYSIgPgo8YSBocmVmPSJodHRwOi8v cmQueWFob28uY29tL21haWxfdXMvcGltbmF2L3dlbGNvbWUvP2h0dHA6Ly9ub3RlcGFkLnlh aG9vLmNvbS8/WVk9NTI1MDkiIHRhcmdldD0iX3RvcCI+Tm90ZXBhZDwvYT4mbmJzcDsmbmJz cDsmbmJzcDsKPC9mb250PjwvdGQ+CjwvdHI+CjwvdGFibGU+PC90ZD4KPC90cj4KPHRyIGhl aWdodD0iMiI+Cjx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49Mj48aW1nIHNyYz0iaHR0cDovL3Vz LmkxLnlpbWcuY29tL3VzLnlpbWcuY29tL2kvcGltL2xpbmUuZ2lmIiBoZWlnaHQ9MiB3aWR0 aD0xMDAlPjwvdGQ+CjwvdHI+CjwvdGFibGU+Cjxicj4gCgoKPHRhYmxlIGNlbGxwYWRkaW5n PTAgY2VsbHNwYWNpbmc9MyB3aWR0aD0iMTAwJSI+PHRyIHZhbGlnbj10b3A+Cjx0ZD4KCgo8 dGFibGUgd2lkdGg9IjEwMCUiIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNpbmc9MCBib3JkZXI9 MD48dHI+PHRkIGJnY29sb3I9IzliYmFkNj4KPHRhYmxlIGNlbGxwYWRkaW5nPTIgY2VsbHNw YWNpbmc9MSBib3JkZXI9MCB3aWR0aD0iMTAwJSI+PHRyPjx0ZD4KPGZvbnQgZmFjZT0iQXJp YWwsSGVsdmV0aWNhIiBzaXplPS0xPjxiPlVucmVhZCBNZXNzYWdlczwvYj4gKDEpIDwvZm9u dD48L3RkPgo8dGQgYWxpZ249cmlnaHQ+CjxhIGhyZWY9ImphdmFzY3JpcHQ6SGVscCgnaHR0 cDovL3JkLnlhaG9vLmNvbS9tYWlsX3VzL2hlbHAvP2h0dHA6Ly9oZWxwLnlhaG9vLmNvbS9o ZWxwL3VzL21haWwvY29udGV4dC9jb250ZXh0LTIzLmh0bWwnKSI+Cjxmb250IGZhY2U9IkFy aWFsLEhlbHZldGljYSIgc2l6ZT0tMT5IZWxwPC9mb250PjwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPC90ZD48L3RyPgo8dHI+PHRkIGFsaWduPWNlbnRlcj4KPHRhYmxlIGNlbGxwYWRkaW5n PTAgY2VsbHNwYWNpbmc9MCB3aWR0aD0iNzUlIj48dHI+PHRkPgo8Yj48YSBocmVmPSIveW0v U2hvd0ZvbGRlcj9ZWT01MjUwOSZib3g9SW5ib3gmWU49MSI+SW5ib3gmbmJzcDsoMSk8L2E+ PC9iPiZuYnNwOwo8L3RkPjwvdHI+PC90YWJsZT4KPGRpdiBhbGlnbj1sZWZ0Pgo8c21hbGw+ Jm5ic3A7ICYjODIyNjsgWW91IGFyZSB1c2luZwozMyUKIApvZiB5b3VyIDYuMCBNQiBsaW1p dAo8YnI+Jm5ic3A7ICYjODIyNjsgPGEgaHJlZj0iL3ltL1Nob3dGb2xkZXI/cmI9SW5ib3gm WVk9NTI1MDkmWU49MSI+R28gdG8gSW5ib3g8L2E+IG9yIDxhIGhyZWY9Ii95bS9FeHRlcm5h bD9HRVQ9MSZibGFua2V0PTEmLmNydW1iPWw0RE5EWlZuV3l2JllZPTUyNTA5Ij5DaGVjayBP dGhlciBNYWlsPC9hPjxicj4KJm5ic3A7ICYjODIyNjsgWWFob28hIE1haWwgZ2l2ZXMgeW91 IDxiPjYuMCBNQiBmb3IgZnJlZSE8L2I+PGJyPgombmJzcDsgJiM4MjI2OyAKIAo8YSBocmVm PSJodHRwczovL29yZGVyaW5nLnlhaG9vLmNvbS9vci95cG0vc3BsYXNoPzU3NyZQa2dzPXVz JTNheW0lM2FzcGFjZSYub3NpZz0zQW56bSIgdGFyZ2V0PSJfYmxhbmsiPgpXb3VsZCB5b3Ug bGlrZSB0byBidXkgYSAxME1CLCAyNU1CLCA1ME1CIG9yIDEwME1CIG1haWxib3g8L2E+Pzxi cj4KJm5ic3A7Cjwvc21hbGw+IAo8L2Rpdj4KPC90ZD48L3RyPgo8L3RhYmxlPgoKCgo8dGFi bGUgd2lkdGg9IjEwMCUiIGNlbGxwYWRkaW5nPTIgY2VsbHNwYWNpbmc9MT48dHI+PHRkIGJn Y29sb3I9IzliYmFkNj4gIAo8Zm9udCBmYWNlPSJBcmlhbCxIZWx2ZXRpY2EiIHNpemU9LTE+ PGI+SW5zaWRlIFlhaG9vITwvYj48L2ZvbnQ+PC90ZD48L3RyPgo8dHI+PHRkPgo8Zm9ybSBz dHlsZT0ibWFyZ2luLWJvdHRvbTowOyIgYWN0aW9uPSJodHRwOi8vcmQueWFob28uY29tL089 MS9ta3RnL21haWwvbW9kL21hbnRsZS9zZWFyY2gvZXZ0PTE3OC8qaHR0cDovL3BlcnNvbmFs cy55YWhvby5jb20vZGlzcGxheS9wZXJzb25hbHMiIHRhcmdldD0iX2JsYW5rIj48aW5wdXQg bmFtZT1mcm9tbW9kIHR5cGU9aGlkZGVuIHZhbHVlPTI+PGlucHV0IG5hbWU9Y3RfaGZ0IHR5 cGU9aGlkZGVuIHZhbHVlPXRhYmxlPjxpbnB1dCBuYW1lPWNyIHR5cGU9aGlkZGVuIHZhbHVl PS1kcmVnaW9uLT48dGFibGUgY2VsbHBhZGRpbmc9MSBjZWxsc3BhY2luZz0wIGJvcmRlcj0w IHdpZHRoPTEwMCU+PHRyPjx0ZCBiZ2NvbG9yPWFhMjI0NCBhbGlnbj1jZW50ZXI+PHRhYmxl IGNlbGxwYWRkaW5nPTEgY2VsbHNwYWNpbmc9MCBib3JkZXI9MCB3aWR0aD0xMDAlPjx0cj48 dGQgYmdjb2xvcj13aGl0ZSBhbGlnbj1jZW50ZXI+PHRhYmxlIGNlbGxwYWRkaW5nPTMgY2Vs bHNwYWNpbmc9MCBib3JkZXI9MCB3aWR0aD0xMDAlIGJnY29sb3I9Y2NjY2ZmPjx0cj48dGQg YWxpZ249Y2VudGVyIGNvbHNwYW49Mz48Zm9udCBmYWNlPWFyaWFsIGNvbG9yPTY2MzM5OT48 Yj5NYWtlIGEgQ29ubmVjdGlvbiB3aXRoIDxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20v Tz0xL21rdGcvbWFpbC9tb2QvbWFudGxlL3NlYXJjaC9ldnQ9MTc4LypodHRwOi8vcGVyc29u YWxzLnlhaG9vLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5ZYWhvbyEgUGVyc29uYWxzPC9hPjwv Yj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249Y2VudGVyPjxpbWcgc3JjPSJodHRw Oi8vdXMuYTEueWltZy5jb20vdXMueWltZy5jb20vaS93dy9tL2hlYXJ0cy5naWYiIHdpZHRo PTUyIGhlaWdodD0yOT48L3RkPjx0ZCBhbGlnbj1jZW50ZXIgbm93cmFwPjx0YWJsZSBjZWxs cGFkZGluZz0yIGNlbGxzcGFjaW5nPTAgYm9yZGVyPTA+PHRyPjx0ZCBhbGlnbj1jZW50ZXI+ PGZvbnQgZmFjZT1hcmlhbCBzaXplPS0xPkknbSBhDQo8c2VsZWN0IG5hbWU9ImNlX3AiPjxv cHRpb24+TWFuPC9vcHRpb24+PG9wdGlvbj5Xb21hbjwvb3B0aW9uPjwvc2VsZWN0Pg0Kc2Vl a2luZyBhDQo8c2VsZWN0IG5hbWU9ImNlX2ciPjxvcHRpb24+V29tYW48L29wdGlvbj48b3B0 aW9uPk1hbjwvb3B0aW9uPjwvc2VsZWN0PjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBhbGln bj1jZW50ZXI+PGZvbnQgZmFjZT1hcmlhbCBzaXplPS0xPkVudGVyIGNpdHkgb3IgWklQL3Bv c3RhbCBjb2RlIDxpbnB1dCB0eXBlPXRleHQgbmFtZT0ucGNzeiBzaXplPTEyIHZhbHVlPSIi IG1heGxlbmd0aD04MD48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249Y2VudGVyPjxp bnB1dCB0eXBlPXN1Ym1pdCB2YWx1ZT0iRmluZCBNeSBNYXRjaCEiPjwvdGQ+PC90cj48L3Rh YmxlPjwvdGQ+PHRkIGFsaWduPWNlbnRlcj48aW1nIHNyYz0iaHR0cDovL3VzLmExLnlpbWcu Y29tL3VzLnlpbWcuY29tL2kvd3cvbS9oZWFydHMuZ2lmIiB3aWR0aD01MiBoZWlnaHQ9Mjk+ PC90ZD48L3RyPjx0cj48dGQgYWxpZ249Y2VudGVyIGNvbHNwYW49Mz48Zm9udCBmYWNlPWFy aWFsIHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9PPTEvbWt0Zy9tYWls L21vZC9tYW50bGUvdG91ci9ldnQ9MTc4Lz9odHRwOi8vcGVyc29uYWxzLnlhaG9vLmNvbS9z dGF0aWMvdG91cjEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPlRha2UgYSBUb3VyIG9mIFlhaG9v ISBQZXJzb25hbHM8L2E+PGZvbnQgY29sb3I9NjYzMzk5PiAtIHdoZXJlIG1pbGxpb25zIG9m IHNpbmdsZXMgbWVldCE8L2ZvbnQ+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90 cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPjwvZm9ybT48dGFibGUgd2lkdGg9MTAwJSBj ZWxscGFkZGluZz0xIGNlbGxzcGFjaW5nPTA+Cjx0cj48dGQgd2lkdGg9NSUgdmFsaWduPXRv cCBhbGlnbj1sZWZ0PjxpbWcgc3JjPSJodHRwOi8vdXMuaTEueWltZy5jb20vdXMueWltZy5j b20vaS91cy9tYWlsL21haWxib3guZ2lmIiB3aWR0aD0yOCBoZWlnaHQ9Mjg+PC90ZD48dGQg dmFsaWduPXRvcCB3aWR0aD05NSU+PGEgaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9tYWls X3VzL3dlbGNvbWUvZXZ0PTIyOS8qaHR0cDovL2JpbGxpbmcubWFpbC55YWhvby5jb20vYm0v TWFpbFBybz8ucmVmZXI9d2VsY29tZTIiIHRhcmdldD1fYmxhbms+TWVAbXktb3duLW5hbWUu Y29tPC9hPjxicj4NCjxzbWFsbD4tIEdldCB0aGUgZW1haWwgYWRkcmVzcyB5b3UndmUgYWx3 YXlzIHdhbnRlZC48L3NtYWxsPjwvdGQ+PC90cj4KPHRyPjx0ZCB3aWR0aD01JSB2YWxpZ249 dG9wIGFsaWduPWxlZnQ+PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55aW1nLmNvbS91cy55aW1n LmNvbS9pL2NoYXQvZXZlbnRzL3lhaG9vL2xvZ28uZ2lmIiB3aWR0aD0yOCBoZWlnaHQ9Mjg+ PC90ZD48dGQgdmFsaWduPXRvcCB3aWR0aD05NSU+PGEgaHJlZj0iaHR0cDovL3JkLnlhaG9v LmNvbS9tYWlsX3VzL3dlbGNvbWUvKmh0dHA6Ly9wcml2YWN5LnlhaG9vLmNvbS8iDQp0YXJn ZXQ9X2JsYW5rPllhaG9vISBQcml2YWN5IFBvbGljeTwvYT48YnI+DQo8c21hbGw+LSBSZWFk IHRoZSB1cGRhdGVkLCBzdHJlYW1saW5lZCBZYWhvbyEgUHJpdmFjeSBQb2xpY3kuPC90ZD48 L3RyPgo8dHI+PHRkIHdpZHRoPTUlIHZhbGlnbj10b3AgYWxpZ249bGVmdD48aW1nIHNyYz0i aHR0cDovL3VzLmkxLnlpbWcuY29tL3VzLnlpbWcuY29tL2kvY2hhdC9ldmVudHMveWFob28v bG9nby5naWYiIHdpZHRoPTI4IGhlaWdodD0yOD48L3RkPjx0ZCB2YWxpZ249dG9wIHdpZHRo PTk1JT48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tL21haWxfdXMvd2VsY29tZS8qaHR0 cDovL3N1cnZleS55YWhvby5jb20vY2dpLWJpbi90ZWNoX3N1cnZleS9zdXJ2ZXkuY2dpP3Nv dXJjZT1tYWlsIiB0YXJnZXQ9Il9ibGFuayI+WWFob28hIFJlc2VhcmNoPC9hPjxicj48c21h bGw+LSBUYWtlIG91ciBJVCBzdXJ2ZXkgYW5kIGVudGVyIG91ciBzd2VlcHN0YWtlcyE8L3Nt YWxsPjwvdGQ+PC90cj4KPHRyPjx0ZCB3aWR0aD01JSB2YWxpZ249dG9wIGFsaWduPWxlZnQ+ PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55aW1nLmNvbS91cy55aW1nLmNvbS9pL3VzL2Nyci9n ci9oai5naWYiIHdpZHRoPTI4IGhlaWdodD0yOD48L3RkPjx0ZCB2YWxpZ249dG9wIHdpZHRo PTk1JT48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tL2NhcmVlcnMvbWFpbC90b3AvKmh0 dHA6Ly93d3cuaG90am9icy5jb20iIHRhcmdldD1fYmxhbms+ICAgSG90Sm9icy5jb208L2E+ PGJyPjxzbWFsbD4gLSA8YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tL2NhcmVlcnMvbWFp bC9zZWFyY2gvKmh0dHA6Ly93d3cuaG90am9icy5jb20iPlNlYXJjaCBqb2JzPC9hPiBvciA8 YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tL2NhcmVlcnMvbWFpbC9wb3N0LypodHRwOi8v d3d3LmhvdGpvYnMuY29tL2h0ZG9jcy9hcHBsaWNhbnQtdW5hdXRob3JpemVkLmh0bWwiPnBv c3QgeW91ciByZXN1bWU8L2E+LiBPcHBvcnR1bml0eSBhd2FpdHMhPC9zbWFsbD48L3RkPjwv dHI+Cjx0cj48dGQgd2lkdGg9NSUgdmFsaWduPXRvcCBhbGlnbj1sZWZ0PjxpbWcgc3JjPSJo dHRwOi8vdXMuaTEueWltZy5jb20vdXMueWltZy5jb20vaS9pY29uL3RyYXZlbC5naWYiPjwv dGQ+PHRkIHZhbGlnbj10b3Agd2lkdGg9OTUlPjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5j b20vbWFpbF91cy93ZWxjb21lLypodHRwOi8vdHJhdmVsLnlhaG9vLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPllhaG9vISBUcmF2ZWw8L2E+PGJyPjxzbWFsbD4gLSBFdmVyeXRoaW5nIHlvdSBu ZWVkIHRvIHBsYW4gYW5kIHB1cmNoYXNlIHlvdXIgbmV4dCB0cmlwLjwvc21hbGw+PC90ZD48 L3RyPgo8dHI+PHRkIHdpZHRoPTUlIHZhbGlnbj10b3AgYWxpZ249bGVmdD48aW1nIHNyYz0i aHR0cDovL3VzLmkxLnlpbWcuY29tL3VzLnlpbWcuY29tL2kvZmkvYmlsbHBheTEuZ2lmIiBo ZWlnaHQ9Mjggd2lkdGg9Mjg+PC90ZD48dGQgdmFsaWduPXRvcCB3aWR0aD05NSU+PGEgaHJl Zj0iaHR0cDovL3JkLnlhaG9vLmNvbS9tYWlsX3VzL3dlbGNvbWUvKmh0dHA6Ly9yZC55YWhv by5jb20vZmluYW5jZS90YXh0cmFja2luZy9tYWlsd2VsY29tZV9peS9wY2xpY2tpZD0yMTky OTMvKmh0dHA6Ly90YXhlcy55YWhvby5jb20vZmlsaW5nLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij5ZYWhvbyEgRmluYW5jZSBUYXggQ2VudGVyPC9hPjxicj48c21hbGw+DQogLSBHZXQgeW91 ciB0YXggcmVmdW5kIEZBU1QhPC9zbWFsbD48L3RkPjwvdHI+CjwvdGFibGU+CjwvdGQ+PC90 cj48L3RhYmxlPgoKPC90ZD4KCjx0ZCB3aWR0aD0iMSIgYmdjb2xvcj0iIzk5OTk5OSIgdmFs aWduPWJvdHRvbT48aHIgc2l6ZT0xPjwvdGQ+Cjx0ZCB2YWxpZ249dG9wIHdpZHRoPTI1MD4K Cgo8dGFibGUgY2VsbHBhZGRpbmc9MCBjZWxsc3BhY2luZz0wIGJvcmRlcj0wIHdpZHRoPSIx MDAlIj4KPC90ZD48L3RyPjx0cj48dGQ+CjwhLS0gYmFkLS0+Cjx0YWJsZSB3aWR0aD0iMTAw JSIgY2VsbHNwYWNpbmc9MCBib3JkZXI9MCBjZWxscGFkZGluZz00Pgo8dHI+PHRkIG5vd3Jh cCBhbGlnbj1jZW50ZXI+Cjx0YWJsZSBib3JkZXI9MCBjZWxscGFkZGluZz0wIGNlbGxzcGFj aW5nPTA+IDx0cj4gPHRkIGFsaWduPWNlbnRlcj48Zm9udCBmYWNlPWFyaWFsIHNpemU9LTI+ QURWRVJUSVNFTUVOVDwvZm9udD48YnI+PGEgaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9N PTIyMzgyMS4xOTU4NjQxLjM0NjMxMDkuMTM1MzY5My9EPW1haWwvUD1tMjJ2dmNhZDExMnYw NTAwL1M9MTUwNTAwMDE0OkxSRUMvQT0xMDI2NTk1L1I9MC8qaHR0cDovL2Nvb3JzbGlnaHQu eWFob28uY29tL2NoZWNraXRvdXQvc3RhdGljL3NwbGFzaC5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+PGltZyBzcmM9Imh0dHA6Ly91cy5hMS55aW1nLmNvbS91cy55aW1nLmNvbS9hL2NvL2Nv b3JzLzMwMHgyNTAuZ2lmIiBhbHQ9IiIgd2lkdGg9IjMwMCIgaGVpZ2h0PSIyNTAiIGJvcmRl cj0iMCI+PC9hPjwvdGQ+IDwvdHI+IDwvdGFibGU+PC90ZD48L3RyPgo8L3RhYmxlPgo8IS0t IGVhZC0tPgo8cD4KCjwhLS0gU3BhY2VJRD0xNTA1MDAwMTQgbG9jPVNFMSBub2FkIC0tPgoK PHRhYmxlIHdpZHRoPSIxMDAlIiBjZWxscGFkZGluZz0yIGNlbGxzcGFjaW5nPTEgYm9yZGVy PTA+PHRyPjx0ZCBiZ2NvbG9yPSM5YmJhZDY+Cjxmb250IGZhY2U9IkFyaWFsLEhlbHZldGlj YSIgc2l6ZT0tMT48Yj5BYm91dCBZYWhvbyEgTWFpbDwvYj48L2ZvbnQ+PC90ZD48L3RyPgo8 dHI+PHRkPgo8c21hbGw+PGI+Q2hlY2sgb3V0IHRoZXNlIGdyZWF0IFlhaG9vISBNYWlsIHNl cnZpY2VzOjwvYj48L3NtYWxsPg0KPHRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgY2Vs bHNwYWNpbmc9Nj4NCiAgPHRyPiANCgk8dGQgdmFsaWduPXRvcD48aW1nIHNyYz0iaHR0cDov L3VzLmkxLnlpbWcuY29tL3VzLnlpbWcuY29tL2kvYnV6ei9tYWlsLmdpZiIgd2lkdGg9MTYg aGVpZ2h0PTE2IGJvcmRlcj0wPjwvdGQ+DQoJPHRkPjxzbWFsbD48Yj5OZWVkIHByb2Zlc3Np b25hbCBlbWFpbCBmb3IgeW91ciBidXNpbmVzcz88L2I+PGJyPg0KCSAgLSBZb3VyIGJ1c2lu ZXNzIGRlc2VydmVzIHRoZSBlbWFpbCBzb2x1dGlvbiB0aGF0IGlzIHByb2Zlc3Npb25hbCwg ZWFzeSwgDQoJICBhbmQgYWZmb3JkYWJsZSAtIDxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5j b20vbWFpbF91cy93ZWxjb21lLz9odHRwOi8vYmlsbGluZy5tYWlsLnlhaG9vLmNvbS95by92 b3JkZXIxPy5wPUImLnJlZmVyPXdlbGNvbWUzIiB0YXJnZXQ9Il9ibGFuayI+WWFob28hIA0K CSAgTWFpbCAtIEJ1c2luZXNzIEVkaXRpb248L2E+Ljwvc21hbGw+PC90ZD4NCiAgPC90cj4N CiAgPHRyPiANCgk8dGQgdmFsaWduPXRvcD48aW1nIHNyYz0iaHR0cDovL3VzLmkxLnlpbWcu Y29tL3VzLnlpbWcuY29tL2kvaGsvaTE2L3lsb2dvLmdpZiIgd2lkdGg9MTYgaGVpZ2h0PTE2 IGJvcmRlcj0wPjwvdGQ+DQoJPHRkPjxzbWFsbD48Yj5XYW50IHRvIGFjY2VzcyB5b3VyIGVt YWlsIHdoaWxlIG9uIHRoZSByb2FkPzwvYj48YnI+DQoJICAtIDxhIGhyZWY9Imh0dHA6Ly9y ZC55YWhvby5jb20vbWFpbF91cy93ZWxjb21lLypodHRwOi8vcGhvbmUueWFob28uY29tLz8u cmVmZXI9eW1haWxhYm91dHltIiB0YXJnZXQ9Il9ibGFuayI+TGlzdGVuIA0KCSAgYW5kIHJl cGx5IHRvIHlvdXIgZW1haWw8L2E+IG92ZXIgdGhlPGJyPg0KCSAgcGhvbmUsIGNoZWNrIHN0 b2NrIHF1b3RlcywgYW5kIG1vcmUhPC9zbWFsbD4gDQoJICANCgk8L3RkPg0KICA8L3RyPg0K DQogIDx0cj4gDQoJPHRkIHZhbGlnbj10b3A+PGltZyBzcmM9Imh0dHA6Ly91cy5pMS55aW1n LmNvbS91cy55aW1nLmNvbS9pL2NhL21haWwvbWFpbHQuZ2lmIj48L3RkPg0KCTx0ZD48c21h bGw+PGI+U2V0IHlvdXIgZGVmYXVsdCBlLW1haWwgcHJvZ3JhbSB0byBZYWhvbyEgTWFpbDwv Yj48YnI+DQoJICAtIDxhIGhyZWY9Ii95bS9NYWlsVG8/RG93bmxvYWQ9MSZZWT01MjUwOSI+ TGVhcm4gaG93PC9hPiB0byBtYWtlIFlhaG9vISANCgkgIE1haWwgeW91ciBkZWZhdWx0IG1h aWwgcHJvZ3JhbS4gRG93bmxvYWQgb3VyIG5ldyAiWWFob28hIE1haWx0byIgYXBwbGljYXRp b24hPC9zbWFsbD48L3RkPg0KICA8L3RyPg0KDQo8L3RhYmxlPjxzbWFsbD4KPEI+UHJlZmVy IE5vbi1GcmFtZXM/PC9CPjo8YnI+CjxhIGhyZWY9Ii95bS9XZWxjb21lP2RvbmY9MSZZWT01 MjUwOSIgdGFyZ2V0PV90b3A+VmlldyBub24tZnJhbWVzIHZlcnNpb248L2E+Lgo8cD4KPC9z bWFsbD4KPC90ZD4KPC90cj4KPC90YWJsZT4KPC90ZD48L3RyPjwvdGFibGU+CjwvdGQ+PC90 cj48L3RhYmxlPgoKPHRhYmxlIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNpbmc9MCBib3JkZXI9 MCB3aWR0aD0iMTAwJSI+PHRyPjx0ZCBiZ2NvbG9yPSNhMGI4Yzg+DQo8dGFibGUgY2VsbHBh ZGRpbmc9MSBjZWxsc3BhY2luZz0xIGJvcmRlcj0wIHdpZHRoPSIxMDAlIj4NCjwhLS0gLSBi dHByb21vIC0tLT4NCjx0ciB2YWxpZ249dG9wIGJnY29sb3I9I2ZmZmZmZj48dGQgYWxpZ249 Y2VudGVyPg0KPGltZyBzcmM9Imh0dHA6Ly91cy5pMS55aW1nLmNvbS91cy55aW1nLmNvbS9p L3VzL3Blci9nci9oZWFydC5naWYiIHdpZHRoPTE3IGhlaWdodD0xNj4mbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tL089MS9mb290ZXIvdHJvdWdoX3Byb21vL2V2 dD0xNzkvP2h0dHA6Ly9wZXJzb25hbHMueWFob28uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPllh aG9vISBQZXJzb25hbHMgLSBXaGVyZSBtaWxsaW9ucyBvZiBzaW5nbGVzIG1lZXQ8L2E+ICZu YnNwOyZuYnNwOzxpbWcgc3JjPSJodHRwOi8vdXMuaTEueWltZy5jb20vdXMueWltZy5jb20v aS91cy9wZXIvZ3IvaGVhcnQuZ2lmIiB3aWR0aD0xNyBoZWlnaHQ9MTY+IA0KPC90ZD48L3Ry Pg0KPCEtLSAtIGV0cHJvbW8gLS0tPg0KPHRyIHZhbGlnbj10b3AgYmdjb2xvcj0jZmZmZmZm Pjx0ZCBhbGlnbj1jZW50ZXI+DQo8Zm9udCBmYWNlPSJhcmlhbCIgc2l6ZT0tMj4NCjxBDQpo cmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL2FkZHJlc3MueWFob28u Y29tLyIgdGFyZ2V0PV9ibGFuaz5BZGRyZXNzJm5ic3A7Qm9vazwvQT4gJiMxODM7IDxBIA0K DQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL2F1Y3Rpb25zLnlh aG9vLmNvbS8iIHRhcmdldD1fYmxhbms+QXVjdGlvbnM8L0E+ICYjMTgzOyA8QSANCg0KaHJl Zj0iaHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9hdXRvcy55YWhvby5jb20v IiB0YXJnZXQ9X2JsYW5rPkF1dG9zPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9y ZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8vYnJpZWZjYXNlLnlhaG9vLmNvbS8iIHRhcmdl dD1fYmxhbms+QnJpZWZjYXNlPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55 YWhvby5jb20vZm9vdGVyLz9odHRwOi8vY2FsZW5kYXIueWFob28uY29tLyIgdGFyZ2V0PV9i bGFuaz5DYWxlbmRhcjwvQT4gJiMxODM7IDxBIA0KDQpocmVmPSJodHRwOi8vcmQueWFob28u Y29tL2Zvb3Rlci8/aHR0cDovL2NhcmVlcnMueWFob28uY29tLyIgdGFyZ2V0PV9ibGFuaz5D YXJlZXJzPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vZm9v dGVyLz9odHRwOi8vY2hhdC55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPkNoYXQ8L0E+ICYj MTgzOyA8QSANCg0KaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9j bGFzc2lmaWVkcy55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPkNsYXNzaWZpZWRzPC9BPiAm IzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8v ZmluYW5jZS55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPkZpbmFuY2U8L0E+ICYjMTgzOyA8 QQ0KDQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL2dhbWVzLnlh aG9vLmNvbS8iIHRhcmdldD1fYmxhbms+R2FtZXM8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0i aHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9nZW9jaXRpZXMueWFob28uY29t LyIgdGFyZ2V0PV9ibGFuaz5HZW9jaXRpZXM8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0iaHR0 cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9ncmVldGluZ3MueWFob28uY29tLyIg dGFyZ2V0PV9ibGFuaz5HcmVldGluZ3M8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0iaHR0cDov L3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9ncm91cHMueWFob28uY29tLyIgdGFyZ2V0 PV9ibGFuaz5Hcm91cHM8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0iaHR0cDovL3JkLnlhaG9v LmNvbS9mb290ZXIvP2h0dHA6Ly93d3cueWFob29saWdhbnMuY29tLyIgdGFyZ2V0PV9ibGFu az5LaWRzPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vZm9v dGVyLz9odHRwOi8vbWFpbC55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPk1haWw8L0E+ICYj MTgzOyA8QSANCg0KaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9t YXBzLnlhaG9vLmNvbS8iIHRhcmdldD1fYmxhbms+TWFwczwvQT4gJiMxODM7IDxBIA0KDQpo cmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL21lbWJlcnMueWFob28u Y29tLyIgdGFyZ2V0PV9ibGFuaz5NZW1iZXImbmJzcDtEaXJlY3Rvcnk8L0E+ICYjMTgzOyA8 QSANCg0KaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9tZXNzZW5n ZXIueWFob28uY29tLyIgdGFyZ2V0PV9ibGFuaz5NZXNzZW5nZXI8L0E+ICYjMTgzOyA8QSAN Cg0KaHJlZj0iaHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9tb2JpbGUueWFo b28uY29tLyIgdGFyZ2V0PV9ibGFuaz5Nb2JpbGU8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0i aHR0cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9tb3ZpZXMueWFob28uY29tLyIg dGFyZ2V0PV9ibGFuaz5Nb3ZpZXM8L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0iaHR0cDovL3Jk LnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9tdXNpYy55YWhvby5jb20vIiB0YXJnZXQ9X2Js YW5rPk11c2ljPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20v Zm9vdGVyLz9odHRwOi8vbXkueWFob28uY29tLyIgdGFyZ2V0PV9ibGFuaz5NeSZuYnNwO1lh aG9vITwvQT4gJiMxODM7IDxBIA0KDQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rl ci8/aHR0cDovL25ld3MueWFob28uY29tLyIgdGFyZ2V0PV9ibGFuaz5OZXdzPC9BPiAmIzE4 MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8vcGF5 ZGlyZWN0LnlhaG9vLmNvbS8iIHRhcmdldD1fYmxhbms+UGF5RGlyZWN0PC9BPiAmIzE4Mzsg PEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8vcGVvcGxl LnlhaG9vLmNvbS8iIHRhcmdldD1fYmxhbms+UGVvcGxlJm5ic3A7U2VhcmNoPC9BPiAmIzE4 MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vTz0xL2Zvb3Rlci8/aHR0cDov L3BlcnNvbmFscy55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPlBlcnNvbmFsczwvQT4gJiMx ODM7IDxBIA0KDQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL3Bo b3Rvcy55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPlBob3RvczwvQT4gJiMxODM7IDxBIA0K DQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL3JhZGlvLnlhaG9v LmNvbS8iIHRhcmdldD1fYmxhbms+UmFkaW88L0E+ICYjMTgzOyA8QSANCg0KaHJlZj0iaHR0 cDovL3JkLnlhaG9vLmNvbS9mb290ZXIvP2h0dHA6Ly9zaG9wcGluZy55YWhvby5jb20vIiB0 YXJnZXQ9X2JsYW5rPlNob3BwaW5nPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9y ZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8vc3BvcnRzLnlhaG9vLmNvbS8iIHRhcmdldD1f Ymxhbms+U3BvcnRzPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9Imh0dHA6Ly9yZC55YWhvby5j b20vZm9vdGVyLz9odHRwOi8vdHYueWFob28uY29tLyIgdGFyZ2V0PV9ibGFuaz5UVjwvQT4g JiMxODM7IDxBIA0KDQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDov L3RyYXZlbC55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPlRyYXZlbDwvQT4gJiMxODM7IDxB IA0KDQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL3dhcmVob3Vz ZS55YWhvby5jb20vIiB0YXJnZXQ9X2JsYW5rPldhcmVob3VzZTwvQT4gJiMxODM7IDxBIA0K DQpocmVmPSJodHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL3dlYXRoZXIueWFo b28uY29tLyIgdGFyZ2V0PV9ibGFuaz5XZWF0aGVyPC9BPiAmIzE4MzsgPEEgDQoNCmhyZWY9 Imh0dHA6Ly9yZC55YWhvby5jb20vZm9vdGVyLz9odHRwOi8veXAueWFob28uY29tLyIgdGFy Z2V0PV9ibGFuaz5ZZWxsb3cmbmJzcDtQYWdlczwvQT4gJiMxODM7IDxBIA0KDQpocmVmPSJo dHRwOi8vcmQueWFob28uY29tL2Zvb3Rlci8/aHR0cDovL2RvY3MueWFob28uY29tL2RvY3Mv ZmFtaWx5L21vcmUuaHRtbCIgdGFyZ2V0PV9ibGFuaz5tb3JlLi4uPC9BPg0KPC9mb250Pg0K PC90ZD48L3RyPjwvdGFibGU+DQo8L3RkPjwvdHI+PC90YWJsZT48YnI+Cjxmb250IHNpemU9 LTE+CjxhIGhyZWY9Imh0dHA6Ly9wcml2YWN5LnlhaG9vLmNvbS9wcml2YWN5L3VzL21haWwv Ij5Qcml2YWN5IFBvbGljeTwvYT4tCjxhIGhyZWY9Imh0dHA6Ly9kb2NzLnlhaG9vLmNvbS9p bmZvL3Rlcm1zLyI+VGVybXMgb2YgU2VydmljZTwvYT4KLQo8YSBocmVmPSJodHRwOi8vZG9j cy55YWhvby5jb20vaW5mby9ndWlkZWxpbmVzL21haWwuaHRtbCI+R3VpZGVsaW5lczwvYT4K PEJSPgo8aT5Db3B5cmlnaHQgJmNvcHk7IDE5OTQtMjAwMgogPGEgaHJlZj0iaHR0cDovL3Jk LnlhaG9vLmNvbS9tYWlsX3VzL3Rvcy8/aHR0cDovL3d3dy55YWhvby5jb20iIHRhcmdldD0i X2JsYW5rIj5ZYWhvbyE8L2E+IEluYy4gQWxsIHJpZ2h0cyByZXNlcnZlZC48L2k+CjwvZm9u dD4KPC9ib2R5Pgo8L2h0bWw+CjwhLS0gVU06IDAuMDAwIC0tPgo8IS0tMC4xMDE5OS0tPgo8 IS0tIGNvbXByZXNzZWQgLS0+Cj== --C8V13N82HP29p01Xdk15M46opdf02uL8X-- From ietf-http-wg-request@tux.w3.org Tue Nov 5 00:30:27 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA55UQB04340 for ; Tue, 5 Nov 2002 00:30:26 -0500 (EST) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA22533 for ; Tue, 5 Nov 2002 00:30:26 -0500 From: srikant.chonnad@siritech.com Received: from yamuna.siri.co.in ([164.164.82.134]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA55UOB04317 for ; Tue, 5 Nov 2002 00:30:25 -0500 (EST) To: ietf-http-wg@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Tue, 5 Nov 2002 11:05:37 +0530 X-MIMETrack: Serialize by Router on Yamuna/Siri(Release 5.0.5 |September 22, 2000) at 11/05/2002 11:06:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=NO_REAL_NAME version=2.31 X-Spam-Level: Subject: HTTP Stack X-Archived-At: http://www.w3.org/mid/OF77EB474D.1FAF8A52-ON65256C68.001E6578@siri.co.in Hi, While implementing a HTTP stack, is there a standard interface that has to be implemented? Regards, Srikant. From ietf-http-wg-request@tux.w3.org Tue Nov 5 11:04:27 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA5G4OB09933 for ; Tue, 5 Nov 2002 11:04:25 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA02659 for ; Tue, 5 Nov 2002 11:04:24 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.5/8.12.5) with ESMTP id gA5G44j1035180; Tue, 5 Nov 2002 09:04:04 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.5/8.12.5/Submit) id gA5G3q53035178; Tue, 5 Nov 2002 09:03:52 -0700 (MST) (envelope-from rousskov) Date: Tue, 5 Nov 2002 09:03:52 -0700 (MST) From: Alex Rousskov To: srikant.chonnad@siritech.com cc: ietf-http-wg@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,FREQ_SPAM_PHRASE,NO_MX_FOR_FROM version=2.31 X-Spam-Level: Subject: Re: HTTP Stack X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211050837250.34472-100000@measurement-factory.com On Tue, 5 Nov 2002 srikant.chonnad@siritech.com wrote: > While implementing a HTTP stack, is there a standard interface that > has to be implemented? I do not know of any, and I doubt a single standard would be ideal for the majority of applications. There are many ways to "support" RFC 2616 and, hence, there are many design decisions you have to make: - client/server/proxy "side" of your stack; do you need to support all sides or a specific side? - how much control do you want the user to have? is the user concerned primarily with sending or receiving content? do they need tight control over content cachability, expiration, types, or even individual HTTP headers? - is performance important? - is portability important? are code size and memory footprint important? - do you need to support caching inside your code? do you need to provide enough hooks for external caching? - is ability to act in the middle of an HTTP transaction important? what about on-the-fly content generation and/or modification? - is ability to support [external] authentication important? do you need to support "https"? - etc. You do not have to start the design from scratch though. It is a good idea to study existing interfaces, especially those that are close to your problem domain. There are several obvious sources of information: Apache server (performance and flexibility), Squid caching proxy (caching and flexibility), Jigsaw server (Java), wget and cUrl clients, as well as related C, C++, and Java libraries that provide lower-level interfaces. In many cases, the developers would be happy to consult you on specific design issues they have faced so that you do not repeat their mistakes. I would recommend that you strive for HTTP/1.1 compliance from the start rather than implementing a quick HTTP/1.0 hack in hope to become compliant later. Based on my experience, that "later" never happens without a significant and costly rewrite of primary code. Note that none of the above applications are fully HTTP/1.1 compliant so you need to be careful when adopting best practices. Finally, make sure that you really need your own stack and cannot adopt or wrap an existing library or application :-). HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Wed Nov 6 11:17:33 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA6GHXB00782 for ; Wed, 6 Nov 2002 11:17:33 -0500 (EST) Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16000 for ; Wed, 6 Nov 2002 11:17:32 -0500 Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127]) by hplb.hpl.hp.com (8.12.1/8.12.1/HP Labs Bristol relay) with ESMTP id gA6GHLSX002916 for ; Wed, 6 Nov 2002 16:17:22 GMT Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA05595 for ; Wed, 6 Nov 2002 16:17:21 GMT Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8]) by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA01085 for ; Wed, 6 Nov 2002 16:17:16 GMT Received: from tiger.cybersurf.com ([209.197.145.194]) by hplb.hpl.hp.com (8.12.1/8.12.1/HP Labs Bristol relay) with ESMTP id gA6GH3SX002844 for ; Wed, 6 Nov 2002 16:17:05 GMT Received: from Ebzmvcoje (ham-uas-2-209197175171.3web.net [209.197.175.171]) by tiger.cybersurf.com (8.12.5/8.12.5) with SMTP id gA6GLbL2001688 for ; Wed, 6 Nov 2002 09:21:41 -0700 Date: Wed, 6 Nov 2002 09:21:37 -0700 Message-Id: <200211061621.gA6GLbL2001688@tiger.cybersurf.com> From: mnot To: http-wg@cuckoo.hpl.hp.com MIME-Version: 1.0 content-type: multipart/mixed; boundary="X0314Us604UB3J48" X-MailScanner: Found to be infected X-MailScanner: Found to be clean X-Spam-Status: No, hits=0.6 required=5.0 tests=FROM_NAME_NO_SPACES,SUBJ_HAS_Q_MARK version=2.31 X-Spam-Level: Subject: {VIRUS?} Literary magazines, and more. X-Archived-At: http://www.w3.org/mid/200211061621.gA6GLbL2001688@tiger.cybersurf.com --X0314Us604UB3J48 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Warning: This message ha= s had one or more attachments removed. Please read the "VirusWarning.txt" a= ttachment(s) for more information.

--X0314Us604UB3J48 Content-Type: text/plain; charset="us-ascii"; name="VirusWarning.txt" Content-Disposition: attachment; filename="VirusWarning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "height.scr" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Wed Nov 6 16:17:15 2002 the virus scanner said: >>> Virus 'W32/Klez-H' found in file ./gA6GH3SX002844/height.scr Windows Screensavers often hide viruses in email (height.scr) Note to Help Desk: Look on hplb.hpl.hp.com in /var/spool/mailscanner/quaran= tine (message gA6GH3SX002844). --=20 Postmaster --X0314Us604UB3J48 Content-Type: application/octet-stream; name=pw[1].htm Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KPHRpdGxlPlBvZXRzICZhbXA7IFdyaXRlcnMs IEluYy48L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8bGluayBocmVmPSIvcHcuY3Nz IiByZWw9InN0eWxlc2hlZXQiIHR5cGU9InRleHQvY3NzIj4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IiNGRkZGRkYiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCIgbWFyZ2lud2lk dGg9IjAiIG1hcmdpbmhlaWdodD0iMCI+DQo8dGFibGUgd2lkdGg9IjEwMCUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgPHRyPiANCgk8dGQgY29s c3Bhbj0iMyIgaWQ9ImJhbm5lciI+IA0KCSAgPGEgaHJlZj0iLyI+PGltZyBzcmM9Ii9ncmFw aGljcy8xcGl4ZWwuZ2lmIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ1IiBib3JkZXI9IjAiIHZz cGFjZT0iMCIgaHNwYWNlPSIwIiBhbGlnbj0ibGVmdCI+PC9hPiANCgkgIDxkaXYgY2xhc3M9 ImJhbm5lci1mbG9hdHJpZ2h0Ij48aW1nIHNyYz0iL2dyYXBoaWNzL25ld19yZXNvdXJjZXNf Zm9yXzUuanBnIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjUwIiB2c3BhY2U9IjAiIGhzcGFjZT0i MCIgYm9yZGVyPSIwIj48L2Rpdj4NCgk8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KCTx0ZCBj b2xzcGFuPSIzIiBjbGFzcz0ibmF2YmFyIiB2YWxpZ249Im1pZGRsZSIgYWxpZ249ImxlZnQi Pg0KCSAgPGRpdiBpZD0ic2VhcmNoZm9ybSI+IA0KCQk8Zm9ybSBtZXRob2Q9InBvc3QiIGFj dGlvbj0iL2NnaS1iaW4vc3luYXBzZS5wbCIgbmFtZT0ic2VhcmNoIj4NCgkJICBTZWFyY2gg Jm5ic3A7IA0KCQkgIDxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJ0ZXJtcyIgc2l6ZT0iMjAi IGNsYXNzPSJuYXZiYXJ0ZXh0Ym94Ij4NCgkJICA8aW5wdXQgdHlwZT0iaW1hZ2UiIGJvcmRl cj0iMCIgbmFtZT0ic2VhcmNoIiBzcmM9Ii9ncmFwaGljcy9uZXdfZ29idXR0b24uZ2lmIiB3 aWR0aD0iNTYiIGhlaWdodD0iMjIiPg0KCQkgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCgkJPC9mb3JtPg0KCSAgPC9kaXY+DQoJICA8ZGl2 IGNsYXNzPSJuYXZiYXJsaW5rcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iL2Fib3V0LyI+QWJvdXQgVXM8L2E+ICZuYnNwO3wgJm5ic3A7PGEgaHJlZj0iL2Nv bnRhY3QuaHRtIj5Db250YWN0IFVzPC9hPiAmbmJzcDt8IA0KCQkmbmJzcDs8YSBocmVmPSIv ZnJpZW5kcy8iPkRvbmF0ZSBOb3c8L2E+ICZuYnNwO3wgJm5ic3A7PGEgaHJlZj0iL2hlbHAu aHRtIiBzdHlsZT0iY3Vyc29yOiBoZWxwOyI+SGVscDwvYT48L2Rpdj4NCgk8L3RkPg0KICA8 L3RyPg0KICA8dHI+IA0KCTx0ZCBjbGFzcz0ibWVudSIgd2lkdGg9IjIwMCIgYWxpZ249Imxl ZnQiIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iL2dyYXBoaWNzL25ld19tZW51X2hlYWRlci5q cGciIHdpZHRoPSIyMDAiIGhlaWdodD0iNDgiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj4gDQoJ ICA8YSBocmVmPSIvbWFnLyI+PGgxPlBvZXRzICZhbXA7IFdyaXRlcnMgTWFnYXppbmU8L2gx PjwvYT4NCiAgICAgPGEgaHJlZj0iL2RpcmVjdHJ5LyI+PGgxPkRpcmVjdG9yeSBvZiBXcml0 ZXJzPC9oMT48L2E+DQoJCTxhIGhyZWY9Ii9zZW1pbmFycy8iPjxoMT5QdWJsaXNoaW5nIFNl bWluYXJzPC9oMT48L2E+DQoJCTxhIGhyZWY9Ii9ydy8iPjxoMT5GdW5kaW5nIGZvciBSZWFk aW5ncy9Xb3Jrc2hvcHM8L2gxPjwvYT4NCgkJPGEgaHJlZj0iL3J3L1dFWC5odG0iPjxoMT5X cml0ZXJzIEV4Y2hhbmdlIENvbnRlc3Q8L2gxPjwvYT4NCgkJPGEgaHJlZj0iL2Jhc2ljX2lu Zm8uaHRtbCI+PGgxPlRvcCBTaXggUXVlc3Rpb25zIFdyaXRlcnMgQXNrPC9oMT48L2E+DQoJ CTxhIGhyZWY9Ii9zcGVhay5odG0iPjxoMT5TcGVha2Vhc3kgTWVzc2FnZSBGb3J1bTwvaDE+ PC9hPg0KCQk8YSBocmVmPSIvbGlua3NfcGFnZXMvIj48aDE+TGlua3MgdG8gT3RoZXIgUmVz b3VyY2VzPC9oMT48L2E+IA0KCQk8cD4mbmJzcDs8L3A+DQoJCTxhIGhyZWY9Ii9hYm91dC8i PjxoMT5OYXRpb25hbCBPZmZpY2U8L2gxPjwvYT4NCgkJPGEgaHJlZj0iL2NhbGlmb3JuaWEv Ij4NCgkgIDxwPkNhbGlmb3JuaWEgQnJhbmNoIE9mZmljZTwvcD4NCgkgIDwvYT4gDQoJICA8 cD4mbmJzcDs8L3A+DQoJICA8YSBocmVmPSJodHRwczovL3d3dy5rYWJsZS5jb20vcHViL3Bv ZXQvc3ViRG9tLmFzcCI+PGltZyBzcmM9Ii9ncmFwaGljcy9zdWJub3dhbjMuZ2lmIiB3aWR0 aD0iMjAwIiBoZWlnaHQ9IjE1IiBib3JkZXI9IjAiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj48 L2E+PGltZyBzcmM9Ii9ncmFwaGljcy8xcGl4ZWwuZ2lmIiB3aWR0aD0iMjAwIiBoZWlnaHQ9 IjgiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj4gDQoJPC90ZD4NCgk8dGQgY2xhc3M9Im1pZC1j b2x1bW4iIHZhbGlnbj0idG9wIiBhbGlnbj0ibGVmdCI+IA0KCSAgPGRpdiBjbGFzcz0ibWlk LWNvbHVtbi1oZWFkZXIiPjxwPldoYXQncyBOZXc8L3A+PC9kaXY+DQoJICA8ZGl2IGNsYXNz PSJtaWQtY29sdW1uLWJsb2NrIj48c3BhbiBjbGFzcz0ibWNiaW1hZ2UiPjxpbWcgc3JjPSIv Z3JhcGhpY3MvbmV3X2Jsb2NrX2ZpbGxlcl81LmpwZyIgd2lkdGg9Ijc1IiBoZWlnaHQ9Ijc1 IiB2c3BhY2U9IjAiIGhzcGFjZT0iMCI+PC9zcGFuPg0KCQk8cD48YSBocmVmPSIvbWFnL25l d3NtYWduZXQuaHRtIj48c3BhbiBjbGFzcz0ibWNiaGVhZGxpbmUiPlRoZSBMYXRlc3QgDQoJ CSAgb24gTGl0ZXJhcnkgTWFnYXppbmVzPC9zcGFuPjwvYT48YnI+DQoJCSAgPGJyPg0KCQkg IEFyZSB5b3UgbG9va2luZyBmb3IgdGhlIGxhdGVzdCBvbiBsaXRlcmFyeSBtYWdhemluZXM/ IENoZWNrIG91dCA8YSBocmVmPSIvbWFnL25ld3NtYWduZXQuaHRtIj5MaXRlcmFyeSANCgkJ ICBNYWdOZXQ8L2E+LCBhIG5ldyBmZWF0dXJlIGZyb20gPGEgaHJlZj0iL21hZy8iPjxpPlBv ZXRzICZhbXA7IFdyaXRlcnMgDQoJCSAgTWFnYXppbmU8L2k+PC9hPi48L3A+DQoJICA8L2Rp dj4NCgkgIDxkaXYgY2xhc3M9Im1pZC1jb2x1bW4tYmxvY2siPjxzcGFuIGNsYXNzPSJtY2Jp bWFnZSI+PGltZyBzcmM9Ii9ncmFwaGljcy9uZXdfYmxvY2tfZmlsbGVyXzMuanBnIiB3aWR0 aD0iNzUiIGhlaWdodD0iNzUiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj48L3NwYW4+IA0KCQk8 cD48YSBocmVmPSIvcHJfaGVhcnN0Lmh0bWwiPjxzcGFuIGNsYXNzPSJtY2JoZWFkbGluZSI+ UG9ldHMgJmFtcDsgV3JpdGVycyANCgkJICBSZWNlaXZlcyAkMTAwLDAwMCBHcmFudDwvc3Bh bj48L2E+PGJyPg0KCQkgIDxicj4NCgkJICBUaGUgV2lsbGlhbSBSYW5kb2xwaCBIZWFyc3Qg Rm91bmRhdGlvbiBvZiBTYW4gRnJhbmNpc2NvIGhhcyBhd2FyZGVkIA0KCQkgIFBvZXRzICZh bXA7IFdyaXRlcnMgYSB0aHJlZS15ZWFyLCAkMTAwLDAwMCBncmFudCB0byBzdXBwb3J0IHRo ZSBvcmdhbml6YXRpb24ncyANCgkJICBwcm9ncmFtcyBpbiBDYWxpZm9ybmlhLiA8YSBocmVm PSIvcHJfaGVhcnN0Lmh0bWwiPlJlYWQgbW9yZS4uLi48L2E+PC9wPg0KCSAgPC9kaXY+DQoJ ICA8ZGl2IGNsYXNzPSJtaWQtY29sdW1uLWJsb2NrIj48c3BhbiBjbGFzcz0ibWNiaW1hZ2Ui PjxpbWcgc3JjPSIvZ3JhcGhpY3MvbmV3X2Jsb2NrX2ZpbGxlcl80LmpwZyIgd2lkdGg9Ijc1 IiBoZWlnaHQ9Ijc1IiB2c3BhY2U9IjAiIGhzcGFjZT0iMCI+PC9zcGFuPiANCgkJPHA+PHNw YW4gY2xhc3M9Im1jYmhlYWRsaW5lIj48Yj48YSBocmVmPSIvbWFnLyI+SGlnaC1Qcm9maWxl IE1hZ2F6aW5lczwvYT48L2I+PC9zcGFuPjxicj4NCgkJICA8YnI+DQoJCSAgSG93IGRvIHlv dSBnZXQgeW91ciBzdG9yeSBhY2NlcHRlZCBieSBhIGhpZ2gtcHJvZmlsZSBtYWdhemluZSBz dWNoIGFzIA0KCQkgIDxpPkdRPC9pPiBvciA8aT5Fc3F1aXJlPC9pPj8gSW4gdGhlIGN1cnJl bnQgaXNzdWUgb2YgPGk+UG9ldHMgJiBXcml0ZXJzIA0KCQkgIE1hZ2F6aW5lPC9pPiwgSm9h bm5hIFNtaXRoIFJha29mZiB0YWxrcyB0byBlaWdodCBmaWN0aW9uIGVkaXRvcnMgYW5kIA0K CQkgIGZpbmRzIG91dCB3aGF0IHRoZXkgd2FudCBhbmQgaG93IHRoZXkgd2FudCBpdC4gPC9w Pg0KCSAgPC9kaXY+DQoJPC90ZD4NCgk8dGQgY2xhc3M9InRoaXJkLWNvbHVtbiIgYWxpZ249 ImNlbnRlciIgdmFsaWduPSJ0b3AiIGJhY2tncm91bmQ9Ii9ncmFwaGljcy8zcmRfY29sdW1u X2JnLmdpZiIgd2lkdGg9IjE4MCI+IA0KCSAgPGRpdiBpZD0ibWFnYmxvY2siPjxhIGhyZWY9 Ii9tYWcvIj48aW1nIHNyYz0iL2dyYXBoaWNzL2NvdmVyLmpwZyIgd2lkdGg9IjE1MCIgaGVp Z2h0PSIxOTMiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIiBib3JkZXI9IjAiPjxicj4NCgkJU2Vw dGVtYmVyL09jdG9iZXIgMjAwMjwvYT48L2Rpdj4NCgkgIDxkaXYgaWQ9ImFkYmxvY2siPjxh IGhyZWY9Ii9hZHMvbHBzV1IuaHRtIj48aW1nIHNyYz0iL2Fkcy9idXR0b25zL2xwc1dSX2J0 bi5naWYiIGJvcmRlcj0iMCIgaHNwYWNlPSIwIiB2c3BhY2U9IjAiIGFsdD0iV3JpdGVyJ3Mg UmVsaWVmIj48L2E+PGJyPg0KCQk8YSBocmVmPSIvYWRzLyI+PGltZyBzcmM9Ii9ncmFwaGlj cy9uZXdfYWRzYnV0dG9uLmdpZiIgd2lkdGg9IjQ2IiBoZWlnaHQ9IjI0IiBib3JkZXI9IjAi IHZzcGFjZT0iMCIgaHNwYWNlPSIwIiBhbGlnbj0ibGVmdCI+PC9hPjxiciBjbGVhcj0iYWxs Ij4gDQoJCTxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Ii9hZHMvIj5TZWUgbW9yZSBhZHMg Zm9yIGNvbmZlcmVuY2VzLCB3b3Jrc2hvcHMsIA0KCQkgIGxpdGVyYXJ5IG1hZ2F6aW5lcywg YW5kIG1vcmUuPC9hPjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgICAgPHA+PC9wPg0KCSAgPHA+ PGEgaHJlZj0iaHR0cDovL3d3dy5tb3JyaXNwdWJsaXNoaW5nLmNvbSI+PGltZyBzcmM9Ii9n cmFwaGljcy9tb3JyaXMuZ2lmIiB3aWR0aD0iMTQwIiBoZWlnaHQ9IjE4MCIgYm9yZGVyPSIw Ij48L2E+PGJyPg0KCQlBRFZFUlRJU0VNRU5UIDwvcD4NCgk8L3RkPg0KICA8L3RyPg0KICA8 dHI+IA0KCTx0ZD4mbmJzcDs8L3RkPg0KCTx0ZD48aW1nIHNyYz0iL2dyYXBoaWNzLzFwaXhl bC5naWYiIHdpZHRoPSIzMDAiIGhlaWdodD0iMSI+PC90ZD4NCgk8dGQ+Jm5ic3A7PC90ZD4N CiAgPC90cj4NCiAgPHRyPiANCgk8dGQgY29sc3Bhbj0iMyI+PGltZyBzcmM9Ii9ncmFwaGlj cy8xcGl4ZWwuZ2lmIiB3aWR0aD0iNjgwIiBoZWlnaHQ9IjEiIHZzcGFjZT0iMCIgaHNwYWNl PSIwIj48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxwIGFsaWduPSJyaWdodCI+PGltZyBz cmM9Ii9ncmFwaGljcy9jb3B5cmlnaHQuZ2lmIiB3aWR0aD0iNDQ4IiBoZWlnaHQ9IjEyIj48 L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQ=9 --X0314Us604UB3J48-- From ietf-http-wg-request@tux.w3.org Mon Nov 11 07:09:03 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gABC93B06912 for ; Mon, 11 Nov 2002 07:09:03 -0500 (EST) Received: from web11305.mail.yahoo.com (web11305.mail.yahoo.com [216.136.131.208]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA05229 for ; Mon, 11 Nov 2002 07:09:02 -0500 Message-ID: <20021111120901.943.qmail@web11305.mail.yahoo.com> Received: from [203.197.166.198] by web11305.mail.yahoo.com via HTTP; Mon, 11 Nov 2002 04:09:01 PST Date: Mon, 11 Nov 2002 04:09:01 -0800 (PST) From: Ges To: ietf-http-wg@w3.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-842445819-1037016541=:831" X-Spam-Status: No, hits=4.6 required=5.0 tests=FROM_NAME_NO_SPACES,SPAM_REDIRECTOR,RCVD_IN_DSBL version=2.31 X-Spam-Level: **** Subject: http servers X-Archived-At: http://www.w3.org/mid/20021111120901.943.qmail@web11305.mail.yahoo.com --0-842445819-1037016541=:831 Content-Type: text/plain; charset=us-ascii Hi, I need to implement a web server for my project. I need help on httpd implementation. I would like to add http and ftp to my web server. Regards Ges --------------------------------- Do you Yahoo!? U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD --0-842445819-1037016541=:831 Content-Type: text/html; charset=us-ascii

Hi,

 I need to implement a web server for my project. I need help on httpd implementation. I would like to add http and ftp to my web server.

Regards

Ges


Do you Yahoo!?
U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD --0-842445819-1037016541=:831-- From ietf-http-wg-request@tux.w3.org Thu Nov 14 07:27:03 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAECR3B25467 for ; Thu, 14 Nov 2002 07:27:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA14636 for ; Thu, 14 Nov 2002 07:27:02 -0500 Received: (qmail 19571 invoked by uid 0); 14 Nov 2002 12:26:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 14 Nov 2002 12:26:31 -0000 From: "Julian Reschke" To: Date: Thu, 14 Nov 2002 13:26:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021111120901.943.qmail@web11305.mail.yahoo.com> Importance: Normal X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 X-Spam-Level: Subject: weak entity tags vs Apache moddav X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEKMFMAA.julian.reschke@gmx.de Hi. In section 3.11 [1], RFC2616 states: "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison." In 13.3.3 [2], it gives the following example: "An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second." Apache moddav indeed returns weak entity tags based on a filesystem timestamp. However, as far as I understand there's no guarantee whatsoever that two entities written within one second indeed can "be substituted for each other with no significant change in semantics". So is this a bug or am I missing something important? Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From ietf-http-wg-request@tux.w3.org Thu Nov 14 11:09:38 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAEG9bB09318 for ; Thu, 14 Nov 2002 11:09:37 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA04595 for ; Thu, 14 Nov 2002 11:09:32 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.5/8.12.5) with ESMTP id gAEG9Sj1038629; Thu, 14 Nov 2002 09:09:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.5/8.12.5/Submit) id gAEG9RCB038628; Thu, 14 Nov 2002 09:09:27 -0700 (MST) (envelope-from rousskov) Date: Thu, 14 Nov 2002 09:09:27 -0700 (MST) From: Alex Rousskov To: Julian Reschke cc: ietf-http-wg@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 X-Spam-Level: Subject: Re: weak entity tags vs Apache moddav X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211140852130.37760-100000@measurement-factory.com On Thu, 14 Nov 2002, Julian Reschke wrote: > In section 3.11 [1], RFC2616 states: > > "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two > entities of a resource only if the entities are equivalent and could be > substituted for each other with no significant change in semantics. A weak > entity tag can only be used for weak comparison." > > Apache moddav indeed returns weak entity tags based on a filesystem > timestamp. However, as far as I understand there's no guarantee whatsoever > that two entities written within one second indeed can "be substituted for > each other with no significant change in semantics". So is this a bug or am > I missing something important? I guess you can call it a violation of the section 3.11 requirement. Whether that violation is a bug depends on what Apache authors intended to implement. I bet the code works as they intended. Webdav does not know about semantics so, ideally, it needs to generate strong tags. However, there is a trade-off between code simplicity and tag strength and it seems like Apache folks resolved this trade-off by declaring a simple-to-implement tag "weak". I do not know whether they knew about the requirement you cite; you may want to check source code for insightful comments. Please note that HTTP is designed in such a way that the above violation is unlikely to cause problems with compliant implementations because weak tag comparison is not used for potentially "dangerous" operations such as merging of ranged responses. In other words, under normal conditions, Apache users will not suffer from the deficiencies of the code, provided webdav explicitly marks the tag as weak. One can always come up with a corner case, of course. If the Web site owner does not think that one second precision is good enough, it should be relatively simple to patch the code to generate strong tags instead (e.g., by appending a sufficiently long and sufficiently random number to the timestamp). Using MD5 checksums would be even better, but also more expensive. This is my interpretation of the situation. I am neither an RFC editor nor Apache developer. HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Fri Nov 15 01:02:02 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAF622B15369 for ; Fri, 15 Nov 2002 01:02:02 -0500 (EST) Received: from yamuna.siri.co.in ([164.164.82.134]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA11875 for ; Fri, 15 Nov 2002 01:01:55 -0500 From: srikant.chonnad@siritech.com To: ietf-http-wg@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 15 Nov 2002 11:36:58 +0530 X-MIMETrack: Serialize by Router on Yamuna/Siri(Release 5.0.5 |September 22, 2000) at 11/15/2002 11:37:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Subject: SSL in HTTP stack X-Archived-At: http://www.w3.org/mid/OF5D0A15BF.46A60E2B-ON65256C72.00212B5C@siri.co.in Hi, I had a doubt. Can SSL implementation be part of the HTTP stack implementation? In that case, for secure HTTP connections, is it OK if we just specify https in the url or should something additional be done. If SSL implemenation is separate, how do we integrate HTTP implementation and SSL implementation? Regards, Srikant. From ietf-http-wg-request@tux.w3.org Fri Nov 15 01:41:10 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAF6fAB18594 for ; Fri, 15 Nov 2002 01:41:10 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA17380 for ; Fri, 15 Nov 2002 01:41:10 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gAF6ewdF049178; Thu, 14 Nov 2002 23:40:58 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gAF6ewnN049177; Thu, 14 Nov 2002 23:40:58 -0700 (MST) (envelope-from rousskov) Date: Thu, 14 Nov 2002 23:40:58 -0700 (MST) From: Alex Rousskov To: srikant.chonnad@siritech.com cc: ietf-http-wg@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 X-Spam-Level: Subject: Re: SSL in HTTP stack X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211142314470.46197-100000@measurement-factory.com On Fri, 15 Nov 2002 srikant.chonnad@siritech.com wrote: > I had a doubt. Can SSL implementation be part of the HTTP stack > implementation? IMO, it is impossible to answer your questions in general. The answer depends on what stack interface you want/need to support. You can wrap everything under one "stack" or provide pluggable SSL wrappers or do something else, depending on your user needs. > In that case, for secure HTTP connections, is it OK if we just > specify https in the url or should something additional be done. It is probably OK provided your stack users do not need any control over SSL parameters. There are a lot of SSL knobs: SSL/TLS protocol versions, certification authorities, encryption algorithms, key lengths, session caching, etc. Some users need them; some do not care as long as everything "works". > If SSL implemenation is separate, how do we integrate HTTP > implementation and SSL implementation? Depends on how you implemented the HTTP stack and what SSL implementation you are using. For example, OpenSSL library provides at least two major integration options: low-level sockets and high-level I/O buffers. An important caveat to keep in mind when integrating HTTP and SSL is that SSL may need to read or write data regardless of the current HTTP "direction" and that SSL may need to do I/Os after HTTP transfer is completed. For example, SSL may need to read data while your HTTP stack is sending a request and, hence, may not expect to read anything until the request is sent. Your code must ensure there are no deadlocks. If you must integrate, read a good book on SSL before you finalize major HTTP stack design decisions. Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Wed Nov 20 09:55:02 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAKEt2B26252 for ; Wed, 20 Nov 2002 09:55:02 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA27709 for ; Wed, 20 Nov 2002 09:55:02 -0500 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAKEsVO02776 for ; Wed, 20 Nov 2002 06:54:31 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAKEsUk02765 for ; Wed, 20 Nov 2002 06:54:30 -0800 (PST) Received: from oracle.com (incq253a.idc.oracle.com [152.69.168.253]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAKEsSI07940 for ; Wed, 20 Nov 2002 07:54:28 -0700 (MST) Message-ID: <3DDBA245.D37332EE@oracle.com> Date: Wed, 20 Nov 2002 20:25:01 +0530 From: Diwakar Shetty Organization: Oracle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-http-wg@w3.org References: <94HD84PUPVSQKTN1VB6B6YS8JGZWGB.3d7785ce@study> <3D782FB9.DF58715B@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01,X_ACCEPT_LANG version=2.43 X-Spam-Level: Subject: Query Parameters in POST method X-Archived-At: http://www.w3.org/mid/3DDBA245.D37332EE@oracle.com In case the method in a URL is a POST method, then is that the query parameters are ignored. e.g: POST /www.google.com/search?hl=en&ie=UTF Will this result in the the query parameters "hl=en&ie=UTF" to be ignored as per HTTP standards ?? Thanks Diwakar From ietf-http-wg-request@tux.w3.org Tue Nov 26 10:58:29 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQFwTr01811 for ; Tue, 26 Nov 2002 10:58:29 -0500 (EST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA26643 for ; Tue, 26 Nov 2002 10:58:29 -0500 Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAQFvwQ23890 for ; Tue, 26 Nov 2002 07:57:58 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAQFvrj23771 for ; Tue, 26 Nov 2002 07:57:53 -0800 (PST) Received: from oracle.com (incq253a.idc.oracle.com [152.69.168.253]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAQFvpB19060 for ; Tue, 26 Nov 2002 08:57:52 -0700 (MST) Message-ID: <3DE39A22.8B0A86E8@oracle.com> Date: Tue, 26 Nov 2002 21:28:26 +0530 From: Diwakar Shetty Organization: Oracle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-http-wg@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.7 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_05_08,X_ACCEPT_LANG version=2.43 X-Spam-Level: Subject: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/3DE39A22.8B0A86E8@oracle.com Following is a para which i read in one book. I could not understand it. Could somebody please elaborate --------------------------------------------------- An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 proxy that did not understand "Connection" but might mistakenly forward it. If the downstream connection also maintained a "Keep-Alive" connection, the proxy in the middle would never receive the closing of the response --------------------------------------------------- My question, is why does it matter. The proxy will just relay whatever comes from actual server to client. Thanks diwakar From ietf-http-wg-request@tux.w3.org Tue Nov 26 11:46:57 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQGkvr10582 for ; Tue, 26 Nov 2002 11:46:57 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA18403 for ; Tue, 26 Nov 2002 11:46:57 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gAQGksdF021243; Tue, 26 Nov 2002 09:46:54 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gAQGks8U021242; Tue, 26 Nov 2002 09:46:54 -0700 (MST) (envelope-from rousskov) Date: Tue, 26 Nov 2002 09:46:54 -0700 (MST) From: Alex Rousskov To: Diwakar Shetty cc: ietf-http-wg@w3.org In-Reply-To: <3DE39A22.8B0A86E8@oracle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211260925360.19283-100000@measurement-factory.com On Tue, 26 Nov 2002, Diwakar Shetty wrote: > Following is a para which i read in one book. I could not understand > it. Could somebody please elaborate > > --------------------------------------------------- > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > proxy that did not understand "Connection" but might mistakenly > forward it. If the downstream connection also maintained a > "Keep-Alive" connection, the proxy in the middle would never receive > the closing of the response > --------------------------------------------------- You may be slightly misquoting the book or the book may be slightly misquoting the protocol -- ``HTTP/1.1 proxy that did not understand Connection'' is an oxymoron. An exact quote from RFC 2616 (section 19.6.2) reads: The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. > My question, is why does it matter. The proxy will just relay > whatever comes from actual server to client. The problem is not with relaying bytes. That works just fine. The problem is with relaying the "end of message" information. Pure HTTP/1.0 applications rely on the [TCP] connection close to detect the end of a message. If the connection happens to be persistent, a pure HTTP/1.0 client will not detect the end of message for quite a while (until the connection is closed, which may happen minutes or even days after the original transaction). Such a delay in end of message detection is bad for at least three reasons: - various resources are wasted for nothing (it takes some CPU cycles, RAM, TPC ports, and possibly even network bandwidth to keep an idle connection open) - the end-user software may be indicating that "download" is still in progress; the user may be tempted to reload the page because it "got stuck", etc. - HTTP/1.0 clients used by an automated software package (e.g., web crawler or rsync) will block the caller preventing scheduled updates and such from happening [on time] HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Tue Nov 26 11:54:05 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQGs5r11602 for ; Tue, 26 Nov 2002 11:54:05 -0500 (EST) Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA20988 for ; Tue, 26 Nov 2002 11:54:05 -0500 Received: (covad.net 20467 invoked from network); 26 Nov 2002 16:54:04 -0000 Received: from h-66-167-13-161.cmbrmaor.covad.net (HELO STUDY) (66.167.13.161) by sun-qmail09 with SMTP; 26 Nov 2002 16:54:04 -0000 To: Diwakar Shetty Cc: ietf-http-wg@w3.org References: <3DE39A22.8B0A86E8@oracle.com> From: Scott Lawrence Date: 26 Nov 2002 11:53:57 -0500 In-Reply-To: <3DE39A22.8B0A86E8@oracle.com> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_05_08,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/u8yzgi862.fsf@world.std.com Diwakar Shetty writes: > --------------------------------------------------- > > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > proxy that did not understand "Connection" but might mistakenly > forward it. If the downstream connection also maintained a > "Keep-Alive" connection, the proxy in the middle would never receive > the closing of the response > --------------------------------------------------- > > My question, is why does it matter. The proxy will just relay > whatever comes from actual server to client. Not at all clear - I can see why you are confused. I don't think that the case described above is actually one of the problem cases (there are others). If by the 'downstream' connection, they mean the proxy-origin connection, then it isn't a problem case. If the origin server honored the Keep-Alive it would send a Content-Length header in the response, and thus the end would not be ambiguous. From ietf-http-wg-request@tux.w3.org Tue Nov 26 12:33:44 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQHXir21862 for ; Tue, 26 Nov 2002 12:33:44 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA04430 for ; Tue, 26 Nov 2002 12:33:43 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gAQHXgdF022291; Tue, 26 Nov 2002 10:33:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gAQHXgRW022290; Tue, 26 Nov 2002 10:33:42 -0700 (MST) (envelope-from rousskov) Date: Tue, 26 Nov 2002 10:33:42 -0700 (MST) From: Alex Rousskov To: Scott Lawrence cc: Diwakar Shetty , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211261014470.19283-100000@measurement-factory.com On 26 Nov 2002, Scott Lawrence wrote: > If the origin server honored the Keep-Alive it would send a > Content-Length header in the response, and thus the end would not be > ambiguous. As far as I can see, the following real-world problems make the above difficult to rely on: - many old HTTP/1.0 clients ignore Content-Length header (because they do not really need it for anything other than double checking the content validity) - some HTTP/1.0 servers include incorrect Content-Length headers and, hence, 1.0 clients SHOULD NOT depend on the Content-Length value being correct (RFC 1945, section 7.2.2) - under certain conditions, the origin server may not include a Content-Length header and a buggy proxy may not append it when downgrading to HTTP/1.0 (or it would not know that it needs to downgrade because the proxy that is going to get stuck has tunneled HTTP/1.1 request version or other headers implying it can handle persistent connections) Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Tue Nov 26 13:38:20 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQIcKr02862 for ; Tue, 26 Nov 2002 13:38:20 -0500 (EST) Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24499 for ; Tue, 26 Nov 2002 13:38:19 -0500 Received: (covad.net 24762 invoked from network); 26 Nov 2002 18:38:19 -0000 Received: from h-66-167-13-161.cmbrmaor.covad.net (HELO STUDY) (66.167.13.161) by sun-qmail09 with SMTP; 26 Nov 2002 18:38:19 -0000 To: Alex Rousskov Cc: Diwakar Shetty , References: From: Scott Lawrence Date: 26 Nov 2002 13:38:12 -0500 In-Reply-To: Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/uznrwgorv.fsf@world.std.com Alex Rousskov writes: > As far as I can see, the following real-world problems make the above > difficult to rely on: > > - many old HTTP/1.0 clients ignore Content-Length header > (because they do not really need it for anything other > than double checking the content validity) > > - some HTTP/1.0 servers include incorrect Content-Length > headers and, hence, 1.0 clients SHOULD NOT depend on the > Content-Length value being correct (RFC 1945, section 7.2.2) > > - under certain conditions, the origin server may not include > a Content-Length header and a buggy proxy may not append > it when downgrading to HTTP/1.0 (or it would not know that > it needs to downgrade because the proxy that is going to > get stuck has tunneled HTTP/1.1 request version or other > headers implying it can handle persistent connections) All of the above are only problems when you have 2 or more buggy implementations in the same transaction - at some point, you just have to throw up your hands and give up. At this point, there is little exuse for deploying any new 1.0 system, and proxies in particular should be using only 1.1. I certainly hope that people who install proxies are checking to see whether or not they really do the right thing, but I have no practical way of checking that. What ever became of the W3C Web Characterization activity? It was originally going to try to answer questions like that. From ietf-http-wg-request@tux.w3.org Tue Nov 26 15:17:49 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAQKHmr16792 for ; Tue, 26 Nov 2002 15:17:49 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA24397 for ; Tue, 26 Nov 2002 15:17:48 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gAQKHkdF027144; Tue, 26 Nov 2002 13:17:47 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gAQKHkDN027143; Tue, 26 Nov 2002 13:17:46 -0700 (MST) (envelope-from rousskov) Date: Tue, 26 Nov 2002 13:17:46 -0700 (MST) From: Alex Rousskov To: Scott Lawrence cc: Diwakar Shetty , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211261300450.19283-100000@measurement-factory.com On 26 Nov 2002, Scott Lawrence wrote: > All of the above are only problems when you have 2 or more buggy > implementations in the same transaction - at some point, you just > have to throw up your hands and give up. Let's not forget the context of this thread. Diwakar Shetty asked to explain the rationale behind the RFC wording. Whether the problem RFC 2616 tried to address still exists is pretty much irrelevant. The problem was very real at the time persistent connection handling was redesigned! > At this point, there is little exuse for deploying any new 1.0 > system, and proxies in particular should be using only 1.1. I > certainly hope that people who install proxies are checking to see > whether or not they really do the right thing, but I have no > practical way of checking that. Many existing systems violate major HTTP/1.1 MUSTs. One of the most popular proxies (Squid) is still HTTP/1.0. It is questionable whether it is better to install a "simple mostly working HTTP/1.0 system" or a "complex mostly working HTTP/1.1 system". There is little excuse for selling seriously broken HTTP/1.1 implementations with known bugs, but that is not the subject of this thread :-). Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Tue Nov 26 23:17:38 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAR4Hcr24164 for ; Tue, 26 Nov 2002 23:17:38 -0500 (EST) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA07903 for ; Tue, 26 Nov 2002 23:17:37 -0500 Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAR4H6q02027 for ; Tue, 26 Nov 2002 20:17:06 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAR4H1201982; Tue, 26 Nov 2002 20:17:02 -0800 (PST) Received: from oracle.com (incq253a.idc.oracle.com [152.69.168.253]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAR4GxB27697; Tue, 26 Nov 2002 21:17:00 -0700 (MST) Message-ID: <3DE4475F.9861E8@oracle.com> Date: Wed, 27 Nov 2002 09:47:35 +0530 From: Diwakar Shetty Organization: Oracle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-http-wg@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.7 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_05_08,X_ACCEPT_LANG version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/3DE4475F.9861E8@oracle.com My replies inline below Alex Rousskov wrote: > On Tue, 26 Nov 2002, Diwakar Shetty wrote: > > > Following is a para which i read in one book. I could not understand > > it. Could somebody please elaborate > > > > --------------------------------------------------- > > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > > proxy that did not understand "Connection" but might mistakenly > > forward it. If the downstream connection also maintained a > > "Keep-Alive" connection, the proxy in the middle would never receive > > the closing of the response > > --------------------------------------------------- > > You may be slightly misquoting the book or the book may be slightly > misquoting the protocol -- ``HTTP/1.1 proxy that did not understand > Connection'' is an oxymoron. An exact quote from RFC 2616 (section > 19.6.2) reads: > > The problem was that some existing 1.0 clients may be > sending Keep-Alive to a proxy server that doesn't understand > Connection, which would then erroneously forward it to the next > inbound server, which would establish the Keep-Alive connection and > result in a hung HTTP/1.0 proxy waiting for the close on the > response. The book is referring to HTTP/1.1 proxy and not HTTP/1.0 proxy If interested, one can refer the book "Web Protocols and Practice" by Balachander Krishnamurthy and Jennifer Rexford, Addison Wesley, May 2001 ISBN 0-201-71088-9 Page no. 289 in the para for "Semantic requirements on an HTTP/1.1 proxy It concludes at the end...."HTTP/1.1 proxies are not permitted to establish a persistent connection with HTTP/1.0 clients > > > > My question, is why does it matter. The proxy will just relay > > whatever comes from actual server to client. > > The problem is not with relaying bytes. That works just fine. The > problem is with relaying the "end of message" information. Pure > HTTP/1.0 applications rely on the [TCP] connection close to detect the > end of a message. If the connection happens to be persistent, a pure > HTTP/1.0 client will not detect the end of message for quite a while > (until the connection is closed, which may happen minutes or even days > But it was the HTTP/1.0 client which sent the "Keep-alive" in the first place Hence it is not pure. It intentionally wants to keep the Connection alive Hence, the client can detect the end of message using "Content-length" sent by the origin server, as mentioned by Scott Perhaps another issue to ponder over would be the different use of "Connection" in HTTP/1.0 and HTTP/1.1 Thanks Diwakar From ietf-http-wg-request@tux.w3.org Wed Nov 27 00:47:24 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAR5lOr06618 for ; Wed, 27 Nov 2002 00:47:24 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA28359 for ; Wed, 27 Nov 2002 00:47:23 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gAR5lKdF040546; Tue, 26 Nov 2002 22:47:20 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gAR5lKqZ040545; Tue, 26 Nov 2002 22:47:20 -0700 (MST) (envelope-from rousskov) Date: Tue, 26 Nov 2002 22:47:20 -0700 (MST) From: Alex Rousskov To: Diwakar Shetty cc: ietf-http-wg@w3.org In-Reply-To: <3DE4475F.9861E8@oracle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211262205070.39393-100000@measurement-factory.com On Wed, 27 Nov 2002, Diwakar Shetty wrote: > > > --------------------------------------------------- > > > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > > > proxy that did not understand "Connection" but might mistakenly > > > forward it. If the downstream connection also maintained a > > > "Keep-Alive" connection, the proxy in the middle would never receive > > > the closing of the response > > > --------------------------------------------------- > > > > You may be slightly misquoting the book or the book may be slightly > > misquoting the protocol -- ``HTTP/1.1 proxy that did not understand > > Connection'' is an oxymoron. An exact quote from RFC 2616 (section > > 19.6.2) reads: > > > > The problem was that some existing 1.0 clients may be > > sending Keep-Alive to a proxy server that doesn't understand > > Connection, which would then erroneously forward it to the next > > inbound server, which would establish the Keep-Alive connection and > > result in a hung HTTP/1.0 proxy waiting for the close on the > > response. > > The book is referring to HTTP/1.1 proxy and not HTTP/1.0 proxy I think the book is misquoting the RFC. Again, there is no such thing as HTTP/1.1 proxy that does not understand Connection header because Connection: support is a MUST. But the terminology is not important here. I suspect you are more interested in a real-world problem the RFC talks about rather than in trying to interpret the book :-). > It concludes at the end...."HTTP/1.1 proxies are not permitted to > establish a persistent connection with HTTP/1.0 clients I hope that's not the end! RFC 2616 comes to the same conclusion, of course, but then continues: The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies. However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence. See section 14.10. The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] As you can see, the problem is solved as long as the client is HTTP/1.1. > > The problem is not with relaying bytes. That works just fine. The > > problem is with relaying the "end of message" information. Pure > > HTTP/1.0 applications rely on the [TCP] connection close to detect the > > end of a message. If the connection happens to be persistent, a pure > > HTTP/1.0 client will not detect the end of message for quite a while > > (until the connection is closed, which may happen minutes or even days > > > > But it was the HTTP/1.0 client which sent the "Keep-alive" in the > first place Hence it is not pure. Proxy is a client in the above context. You need to draw a picture: client C (end-client or proxy) (issues Connection: keep-alive) | | proxy P (forwards Connection: keep-alive, does not understand persistency and works as a tunnel) | | server S (origin or proxy) (establishes persistent connection: technically with proxy A, but, essentially, with client C, which is wrong) Now, server S will not close the connection after the response is sent. End-client C may be fine because it knows how to detect the end of the response. Proxy P will get stuck though because it will wait for connection close from server S. > It intentionally wants to keep the Connection alive Hence, the > client can detect the end of message using "Content-length" sent by > the origin server, as mentioned by Scott True, but the problem is not with client C. The problem is with proxy P. See above. Now imagine that proxy P does not forward small responses until they are "completely received"; in this case, client C gets stuck as well! HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance From ietf-http-wg-request@tux.w3.org Wed Nov 27 14:20:22 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gARJKMr02660 for ; Wed, 27 Nov 2002 14:20:22 -0500 (EST) Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01348 for ; Wed, 27 Nov 2002 14:20:18 -0500 Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id LAA08855; Wed, 27 Nov 2002 11:20:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.3/8.12.2) with SMTP id gARJKGgD028492; Wed, 27 Nov 2002 11:20:16 -0800 (PST) From: Jeffrey Mogul Message-Id: <200211271920.gARJKGgD028492@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: Alex Rousskov cc: Diwakar Shetty , ietf-http-wg@w3.org In-reply-to: Your message of "Tue, 26 Nov 2002 22:47:20 MST." X-Organization: Hewlett-Packard Western Research Lab Date: Wed, 27 Nov 2002 11:20:16 -0800 X-Mts: smtp X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_13_21, X_AUTH_WARNING version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/200211271920.gARJKGgD028492@wera.hpl.hp.com Alex wrote: I think the book is misquoting the RFC. Actually, I think Diwakar Shetty's original message misquoted the book. (Alex guess this right.) He wrote: Following is a para which i read in one book. An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 proxy that did not understand "Connection" but might mistakenly forward it. If the downstream connection also maintained a "Keep-Alive" connection, the proxy in the middle would never receive the closing of the response He later identified this as from page 289 in Krishnamurthy & Rexford. The actual paragraph is much longer (the quote above is not the whole paragraph!) and what the paragraph in the book actually says is: [2 sentences I'm not quoting] However, interaction between the Connection header and Keep-Alive header could result in a hung connection. This occured because an HTTP/1.0 client could send a "Keep-Alive" header to a proxy that did not understand "Connection" but might mistakenly forward it. If the downstream connection also maintained a "Keep-Alive" connection, the proxy in the middle would never receive the closing of the response. To avoid such problems, HTTP/1.1 proxies are not permitted to establish a persistent connection with HTTP/1.0 clients. So the discussion on this mailing list has been misguided because the book never mentioned "a HTTP/1.1 proxy that did not understand 'Connection'". I'm sure the Krishnamurthy & Rexford book does have bugs, and I suspect this paragraph could have been clearer if the phrase "to a proxy" had been "to an HTTP/1.0 proxy". But from now on, let's insist on accurate quotes before discussing whether some publication got the story right. -Jeff From ietf-http-wg-request@tux.w3.org Wed Nov 27 19:29:53 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS0TrA23606 for ; Wed, 27 Nov 2002 19:29:53 -0500 (EST) Received: from dhcp-sna-67.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA23271 for ; Wed, 27 Nov 2002 19:29:53 -0500 Received: from dhcp-sna-67.day.com (localhost.day.com [127.0.0.1] (may be forged)) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id gARNfCCm010241; Wed, 27 Nov 2002 15:41:12 -0800 (PST) Date: Wed, 27 Nov 2002 15:40:46 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 X-Spam-Level: Subject: Re: weak entity tags vs Apache moddav X-Archived-At: http://www.w3.org/mid/A6A0587E-0261-11D7-B548-000393753936@apache.org > Apache moddav indeed returns weak entity tags based on a filesystem > timestamp. However, as far as I understand there's no guarantee whatsoever > that two entities written within one second indeed can "be substituted for > each other with no significant change in semantics". So is this a bug or > am > I missing something important? No, it is just over-specification. It is impossible for an HTTP server to know the semantics of a representation. However, if one representation overwrites another such that both are valid responses to GET on the same resource, then both are clearly intended to represent that resource. What the spec is trying to say is that a weak etag cannot be used to test for byte equivalence of the representation, unlike a strong etag. The HTTP components don't need to know why. Apache etags are configurable, so the resource owner can determine what is sufficient for differentiation based on the resource implementation. We used to include the system inode by default, but that proved harmful for server farms using rsync or raid mirrors. ....Roy From ietf-http-wg-request@tux.w3.org Thu Nov 28 05:15:13 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASAFCA03981 for ; Thu, 28 Nov 2002 05:15:12 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA22933 for ; Thu, 28 Nov 2002 05:15:12 -0500 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gASAEfm29224 for ; Thu, 28 Nov 2002 02:14:41 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gASAEeD29194; Thu, 28 Nov 2002 02:14:40 -0800 (PST) Received: from oracle.com (incq253a.idc.oracle.com [152.69.168.253]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gASAEbI24956; Thu, 28 Nov 2002 03:14:38 -0700 (MST) Message-ID: <3DE5ECB1.27D3187E@oracle.com> Date: Thu, 28 Nov 2002 15:45:13 +0530 From: Diwakar Shetty Organization: Oracle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mogul CC: Alex Rousskov , ietf-http-wg@w3.org References: <200211271920.gARJKGgD028492@wera.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_08_13,X_ACCEPT_LANG version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/3DE5ECB1.27D3187E@oracle.com The original para was a very long one. So to reduce it, I added the important sentences only. Also the whole para was in the section for "Semantic requirements on an HTTP/1.1 proxy." Hence, it made sense to replace the "Proxy" in the para with "HTTP/1.1 proxy" In fact, thoughout that para all mention was to HTTP/1.1 proxy with the exception of only one place where "only" proxy was mentioned So I believe, I did not misquote the book And niether did the book misquote the RFC because the author never said that it was as per the RFC in the first place In fact, I am more concerned with how things work (or rather does not work in the current discussion topic) practically rather than what the RFC says But anyway, will henceforth send the quotes on "as-is" basis :-) Thanks Diwakar Jeffrey Mogul wrote: > Alex wrote: > > I think the book is misquoting the RFC. > > Actually, I think Diwakar Shetty's original message misquoted the book. > (Alex guess this right.) He wrote: > > Following is a para which i read in one book. > > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > proxy that did not understand "Connection" but might mistakenly > forward it. If the downstream connection also maintained a > "Keep-Alive" connection, the proxy in the middle would never > receive the closing of the response > > He later identified this as from page 289 in Krishnamurthy & Rexford. > The actual paragraph is much longer (the quote above is not the > whole paragraph!) and what the paragraph in the book actually says is: > > [2 sentences I'm not quoting] > However, interaction between the Connection header and > Keep-Alive header could result in a hung connection. This > occured because an HTTP/1.0 client could send a "Keep-Alive" > header to a proxy that did not understand "Connection" but > might mistakenly forward it. If the downstream connection also > maintained a "Keep-Alive" connection, the proxy in the middle > would never receive the closing of the response. To avoid such > problems, HTTP/1.1 proxies are not permitted to establish a > persistent connection with HTTP/1.0 clients. > > So the discussion on this mailing list has been misguided because > the book never mentioned "a HTTP/1.1 proxy that did not understand > 'Connection'". > > I'm sure the Krishnamurthy & Rexford book does have bugs, and > I suspect this paragraph could have been clearer if the phrase > "to a proxy" had been "to an HTTP/1.0 proxy". But from now on, > let's insist on accurate quotes before discussing whether some > publication got the story right. > > -Jeff From ietf-http-wg-request@tux.w3.org Thu Nov 28 07:47:14 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASClDA24988 for ; Thu, 28 Nov 2002 07:47:13 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA19149 for ; Thu, 28 Nov 2002 07:47:13 -0500 Received: (qmail 18067 invoked by uid 0); 28 Nov 2002 12:46:41 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 28 Nov 2002 12:46:41 -0000 From: "Julian Reschke" To: "Roy T. Fielding" Cc: Date: Thu, 28 Nov 2002 13:46:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: Subject: RE: weak entity tags vs Apache moddav X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDHFOAA.julian.reschke@gmx.de > From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]On > Behalf Of Roy T. Fielding > Sent: Thursday, November 28, 2002 12:41 AM > To: Julian Reschke > Cc: ietf-http-wg@w3.org > Subject: Re: weak entity tags vs Apache moddav > .. Roy, thanks for the feedback... > > Apache moddav indeed returns weak entity tags based on a filesystem > > timestamp. However, as far as I understand there's no guarantee whatsoever > > that two entities written within one second indeed can be substituted for > > each other with no significant change in semantics". So is this a bug or > > am I missing something important? > > No, it is just over-specification. It is impossible for an HTTP server > to know the semantics of a representation. However, if one representation Yes. > overwrites another such that both are valid responses to GET on the > same resource, then both are clearly intended to represent that resource. Sure. They are the same resource. But if the resource is modified multiple times within a clock interval, the server (Apache) will return the same weak entity tag, so user agents may not get the latest modification if they do a conditional GET. I'd say that in the case where another client actually did succeed to modifiy the resource twice (in the same clock interval) using PUT, this is wrong. > What the spec is trying to say is that a weak etag cannot be used to > test for byte equivalence of the representation, unlike a strong etag. > The HTTP components don't need to know why. OK. So I conclude that a generic authoring client (one that has no concept of semantically equivalent entities) MUST NOT use weak entitty tags to protect itself from lost updates upon PUT. Correct? > Apache etags are configurable, so the resource owner can determine what > is sufficient for differentiation based on the resource implementation. > We used to include the system inode by default, but that proved harmful > for server farms using rsync or raid mirrors. Interesting. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From ietf-http-wg-request@tux.w3.org Thu Nov 28 15:21:33 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASKLXA04753 for ; Thu, 28 Nov 2002 15:21:33 -0500 (EST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05943 for ; Thu, 28 Nov 2002 15:21:33 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id gASKLUdF097378; Thu, 28 Nov 2002 13:21:30 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id gASKLTWP097377; Thu, 28 Nov 2002 13:21:29 -0700 (MST) (envelope-from rousskov) Date: Thu, 28 Nov 2002 13:21:29 -0700 (MST) From: Alex Rousskov To: Diwakar Shetty cc: ietf-http-wg@w3.org In-Reply-To: <3DE5ECB1.27D3187E@oracle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 X-Spam-Level: Subject: Re: Connection:Keep-Alive and Proxies X-Archived-At: http://www.w3.org/mid/Pine.BSF.4.44.0211281316120.96816-100000@measurement-factory.com On Thu, 28 Nov 2002, Diwakar Shetty wrote: > In fact, I am more concerned with how things work (or rather does > not work in the current discussion topic) practically rather than > what the RFC says In this particular case, the RFC actually explains how things do not work [well] with HTTP/1.0 and how they work [well] with HTTP/1.1, which is what you seem to be after. Have you received good-enough answers? Or are there still some doubts you need the group to qualify? If there are, what are they? Thanks, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance