Error

From nevin@bountifulbaby.com Tue Dec 27 03:59:45 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Squeak Http GET broken? Date: Mon, 26 Dec 2005 20:59:43 -0700 Message-ID: <43B0BC2F.4010403@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7670088816753387792==" --===============7670088816753387792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This should be simple, but it's got me stumped. First, plug the following URL into any browser (Mozilla, IE,=20 Thunderbird, Safari, or whatever, all one line in the URL panel): =20 http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D

6406 Ivy=20 LaneGreenbeltMD

You should get back the following response from the shippingapis.com=20 machine: 80040b19 XML Syntax Error: Error getting USERID=20 attribute. UspsCom::DoAuth And, this is how it should be. And, I would like to duplicate this=20 behavior via Squeak code. So, I try, for example, the following: HTTPClient httpGetDocument:=20 'http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D6406 Ivy=20 LaneGreenbeltMD' I would think that the above would be the programmatic equivalent of the=20 URL I typed into Thunderbird (I also tried it with Safari, and both=20 Safari and Thunderbird gave me the same results). But when I do it=20 programmatically in Squeak, I get back this response: HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Tue, 27 Dec 2005 03:46:44 GMT Content-Type: text/html Content-Length: 87ErrorThe=20 parameter is incorrect. I was expecting the "XML Syntax Error" response that Thunderbird (as=20 well as Safari) gave me instead of this nonsense. But I instead got=20 back something totally different. Why? OK, let's try Scamper. So, I plug in the URL I mentioned, and I get the=20 following response in Scamper: error occured retrieving=20 http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D

6406 Ivy=20 LaneGreenbeltMD

:=20 HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Tue, 27 Dec 2005 03:50:47 GMT Content-Type: text/html Content-Length: 87ErrorThe=20 parameter is incorrect. So, Scamper is also giving me something different from the "XML Syntax=20 Error" response I was expecting. Why? I've tried every combination of GET and/or POST I could think of. I=20 just don't understand why Squeak is giving me a different result than=20 Thunderbird gives me. Anybody know? In case you are curious, if I include my login ID as an XML arg of the=20 URL, the shippingapis.com machine will validate my address(es) that I=20 pass to it. I just didn't think it would be a good idea to post my=20 login ID. Besides, it is unnecessary to do so, because if I solve the=20 above problem, I will solve my *real* problem, and will be able to=20 programmatically validate any US-based address. Anybody know why Squeak is giving me different results than the web=20 browsers do? Nevin --===============7670088816753387792== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1J U08tODg1OS0xIiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPgo8L2hlYWQ+Cjxib2R5IGJnY29s b3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPgo8YmlnPlRoaXMgc2hvdWxkIGJlIHNpbXBsZSwg YnV0IGl0J3MgZ290IG1lIHN0dW1wZWQuPGJyPgo8YnI+CkZpcnN0LCBwbHVnIHRoZSBmb2xsb3dp bmcgVVJMIGludG8gYW55IGJyb3dzZXIgKE1vemlsbGEsIElFLApUaHVuZGVyYmlyZCwgU2FmYXJp LCBvciB3aGF0ZXZlciwgYWxsIG9uZSBsaW5lIGluIHRoZSBVUkwgcGFuZWwpOjwvYmlnPjxicj4K PGJyPgombmJzcDsmbmJzcDsgPHR0PjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhy ZWY9Imh0dHA6Ly90ZXN0aW5nLnNoaXBwaW5nYXBpcy5jb20vU2hpcHBpbmdBUElUZXN0LmRsbD9B UEk9VmVyaWZ5JlhNTD0iPmh0dHA6Ly90ZXN0aW5nLnNoaXBwaW5nYXBpcy5jb20vU2hpcHBpbmdB UElUZXN0LmRsbD9BUEk9VmVyaWZ5JmFtcDtYTUw9PC9hPiZsdDtBZGRyZXNzVmFsaWRhdGVSZXF1 ZXN0CiZndDsmbHQ7QWRkcmVzcwpJRD0iMCImZ3Q7Jmx0O0FkZHJlc3MxJmd0OyZsdDsvQWRkcmVz czEmZ3Q7Jmx0O0FkZHJlc3MyJmd0OzY0MDYgSXZ5CkxhbmUmbHQ7L0FkZHJlc3MyJmd0OyZsdDtD aXR5Jmd0O0dyZWVuYmVsdCZsdDsvQ2l0eSZndDsmbHQ7U3RhdGUmZ3Q7TUQmbHQ7L1N0YXRlJmd0 OyZsdDtaaXA1Jmd0OyZsdDsvWmlwNSZndDsmbHQ7WmlwNCZndDsmbHQ7L1ppcDQmZ3Q7Jmx0Oy9B ZGRyZXNzJmd0OyZsdDsvQWRkcmVzc1ZhbGlkYXRlUmVxdWVzdCZndDs8L3R0Pjxicj4KPGJyPgo8 YmlnPllvdSBzaG91bGQgZ2V0IGJhY2sgdGhlIGZvbGxvd2luZyByZXNwb25zZSBmcm9tIHRoZQpz aGlwcGluZ2FwaXMuY29tIG1hY2hpbmU6PC9iaWc+PGJyPgo8YnI+CiZuYnNwOyZuYnNwOyA8dHQ+ Jmx0O0Vycm9yJmd0Ozxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtOdW1iZXImZ3Q7ODAwNDBi MTkmbHQ7L051bWJlciZndDs8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7RGVzY3JpcHRpb24m Z3Q7WE1MIFN5bnRheCBFcnJvcjogRXJyb3IgZ2V0dGluZyBVU0VSSUQKYXR0cmlidXRlLiZsdDsv RGVzY3JpcHRpb24mZ3Q7PGJyPgombmJzcDsmbmJzcDsmbmJzcDsgJmx0O1NvdXJjZSZndDtVc3Bz Q29tOjpEb0F1dGgmbHQ7L1NvdXJjZSZndDs8YnI+CiZsdDsvRXJyb3ImZ3Q7PGJyPgo8L3R0Pjxi aWc+PGJyPgpBbmQsIHRoaXMgaXMgaG93IGl0IHNob3VsZCBiZS4mbmJzcDsgQW5kLCBJIHdvdWxk IGxpa2UgdG8gZHVwbGljYXRlIHRoaXMKYmVoYXZpb3IgdmlhIFNxdWVhayBjb2RlLiZuYnNwOyBT bywgSSB0cnksIGZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nOjxicj4KPGJyPgo8c21hbGw+PHR0 PkhUVFBDbGllbnQgaHR0cEdldERvY3VtZW50OgonPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cDovL3Rlc3Rpbmcuc2hpcHBpbmdhcGlzLmNvbS9TaGlwcGluZ0FQSVRl c3QuZGxsP0FQST1WZXJpZnkmWE1MPSI+aHR0cDovL3Rlc3Rpbmcuc2hpcHBpbmdhcGlzLmNvbS9T aGlwcGluZ0FQSVRlc3QuZGxsP0FQST1WZXJpZnkmYW1wO1hNTD08L2E+Jmx0O0FkZHJlc3NWYWxp ZGF0ZVJlcXVlc3QmZ3Q7Jmx0O0FkZHJlc3MKSUQ9IjAiJmd0OyZsdDtBZGRyZXNzMSZndDsmbHQ7 L0FkZHJlc3MxJmd0OyZsdDtBZGRyZXNzMiZndDs2NDA2IEl2eQpMYW5lJmx0Oy9BZGRyZXNzMiZn dDsmbHQ7Q2l0eSZndDtHcmVlbmJlbHQmbHQ7L0NpdHkmZ3Q7Jmx0O1N0YXRlJmd0O01EJmx0Oy9T dGF0ZSZndDsmbHQ7WmlwNSZndDsmbHQ7L1ppcDUmZ3Q7Jmx0O1ppcDQmZ3Q7Jmx0Oy9aaXA0Jmd0 OyZsdDsvQWRkcmVzcyZndDsmbHQ7L0FkZHJlc3NWYWxpZGF0ZVJlcXVlc3QmZ3Q7JzwvdHQ+PGJy Pgo8L3NtYWxsPjxicj4KSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSB3b3VsZCBiZSB0aGUg cHJvZ3JhbW1hdGljIGVxdWl2YWxlbnQgb2YKdGhlIFVSTCBJIHR5cGVkIGludG8gVGh1bmRlcmJp cmQgKEkgYWxzbyB0cmllZCBpdCB3aXRoIFNhZmFyaSwgYW5kIGJvdGgKU2FmYXJpIGFuZCBUaHVu ZGVyYmlyZCBnYXZlIG1lIHRoZSBzYW1lIHJlc3VsdHMpLiZuYnNwOyBCdXQgd2hlbiBJIGRvIGl0 CnByb2dyYW1tYXRpY2FsbHkgaW4gU3F1ZWFrLCBJIGdldCBiYWNrIHRoaXMgcmVzcG9uc2U6PGJy Pgo8YnI+CjxzbWFsbD48dHQ+SFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0PGJyPgpTZXJ2ZXI6IE1p Y3Jvc29mdC1JSVMvNS4wPGJyPgpEYXRlOiBUdWUsIDI3IERlYyAyMDA1IDAzOjQ2OjQ0IEdNVDxi cj4KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw8YnI+CkNvbnRlbnQtTGVuZ3RoOgo4NyZsdDtodG1s Jmd0OyZsdDtoZWFkJmd0OyZsdDt0aXRsZSZndDtFcnJvciZsdDsvdGl0bGUmZ3Q7Jmx0Oy9oZWFk Jmd0OyZsdDtib2R5Jmd0O1RoZQpwYXJhbWV0ZXIgaXMgaW5jb3JyZWN0LiAmbHQ7L2JvZHkmZ3Q7 Jmx0Oy9odG1sJmd0OzwvdHQ+PC9zbWFsbD48YnI+Cjxicj4KSSB3YXMgZXhwZWN0aW5nIHRoZSAi WE1MIFN5bnRheCBFcnJvciIgcmVzcG9uc2UgdGhhdCBUaHVuZGVyYmlyZCAoYXMKd2VsbCBhcyBT YWZhcmkpIGdhdmUgbWUgaW5zdGVhZCBvZiB0aGlzIG5vbnNlbnNlLiZuYnNwOyBCdXQgSSBpbnN0 ZWFkIGdvdApiYWNrIHNvbWV0aGluZyB0b3RhbGx5IGRpZmZlcmVudC4mbmJzcDsgV2h5Pzxicj4K PGJyPgpPSywgbGV0J3MgdHJ5IFNjYW1wZXIuJm5ic3A7IFNvLCBJIHBsdWcgaW4gdGhlIFVSTCBJ IG1lbnRpb25lZCwgYW5kIEkgZ2V0CnRoZSBmb2xsb3dpbmcgcmVzcG9uc2UgaW4gU2NhbXBlcjo8 YnI+CjxzbWFsbD48dHQ+PGJyPgplcnJvciBvY2N1cmVkIHJldHJpZXZpbmcKPGEgY2xhc3M9Im1v ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3Rlc3Rpbmcuc2hpcHBpbmdhcGlzLmNv bS9TaGlwcGluZ0FQSVRlc3QuZGxsP0FQST1WZXJpZnkmWE1MPSI+aHR0cDovL3Rlc3Rpbmcuc2hp cHBpbmdhcGlzLmNvbS9TaGlwcGluZ0FQSVRlc3QuZGxsP0FQST1WZXJpZnkmYW1wO1hNTD08L2E+ Jmx0O0FkZHJlc3NWYWxpZGF0ZVJlcXVlc3QKJmd0OyZsdDtBZGRyZXNzCklEPSIwIiZndDsmbHQ7 QWRkcmVzczEmZ3Q7Jmx0Oy9BZGRyZXNzMSZndDsmbHQ7QWRkcmVzczImZ3Q7NjQwNiBJdnkKTGFu ZSZsdDsvQWRkcmVzczImZ3Q7Jmx0O0NpdHkmZ3Q7R3JlZW5iZWx0Jmx0Oy9DaXR5Jmd0OyZsdDtT dGF0ZSZndDtNRCZsdDsvU3RhdGUmZ3Q7Jmx0O1ppcDUmZ3Q7Jmx0Oy9aaXA1Jmd0OyZsdDtaaXA0 Jmd0OyZsdDsvWmlwNCZndDsmbHQ7L0FkZHJlc3MmZ3Q7Jmx0Oy9BZGRyZXNzVmFsaWRhdGVSZXF1 ZXN0Jmd0OzoKSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0PGJyPgpTZXJ2ZXI6IE1pY3Jvc29mdC1J SVMvNS4wPGJyPgpEYXRlOiBUdWUsIDI3IERlYyAyMDA1IDAzOjUwOjQ3IEdNVDxicj4KQ29udGVu dC1UeXBlOiB0ZXh0L2h0bWw8YnI+CkNvbnRlbnQtTGVuZ3RoOgo4NyZsdDtodG1sJmd0OyZsdDto ZWFkJmd0OyZsdDt0aXRsZSZndDtFcnJvciZsdDsvdGl0bGUmZ3Q7Jmx0Oy9oZWFkJmd0OyZsdDti b2R5Jmd0O1RoZQpwYXJhbWV0ZXIgaXMgaW5jb3JyZWN0LiAmbHQ7L2JvZHkmZ3Q7Jmx0Oy9odG1s Jmd0OzwvdHQ+PC9zbWFsbD48YnI+Cjxicj4KU28sIFNjYW1wZXIgaXMgYWxzbyBnaXZpbmcgbWUg c29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIHRoZSAiWE1MIFN5bnRheApFcnJvciIgcmVzcG9uc2Ug SSB3YXMgZXhwZWN0aW5nLiZuYnNwOyBXaHk/PGJyPgo8YnI+CkkndmUgdHJpZWQgZXZlcnkgY29t YmluYXRpb24gb2YgR0VUIGFuZC9vciBQT1NUIEkgY291bGQgdGhpbmsgb2YuJm5ic3A7IEkKanVz dCBkb24ndCB1bmRlcnN0YW5kIHdoeSBTcXVlYWsgaXMgZ2l2aW5nIG1lIGEgZGlmZmVyZW50IHJl c3VsdCB0aGFuClRodW5kZXJiaXJkIGdpdmVzIG1lLiZuYnNwOyBBbnlib2R5IGtub3c/PGJyPgo8 YnI+CkluIGNhc2UgeW91IGFyZSBjdXJpb3VzLCBpZiBJIGluY2x1ZGUgbXkgbG9naW4gSUQgYXMg YW4gWE1MIGFyZyBvZiB0aGUKVVJMLCB0aGUgc2hpcHBpbmdhcGlzLmNvbSBtYWNoaW5lIHdpbGwg dmFsaWRhdGUgbXkgYWRkcmVzcyhlcykgdGhhdCBJCnBhc3MgdG8gaXQuJm5ic3A7IEkganVzdCBk aWRuJ3QgdGhpbmsgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gcG9zdCBteQpsb2dpbiBJRC4m bmJzcDsgQmVzaWRlcywgaXQgaXMgdW5uZWNlc3NhcnkgdG8gZG8gc28sIGJlY2F1c2UgaWYgSSBz b2x2ZSB0aGUKYWJvdmUgcHJvYmxlbSwgSSB3aWxsIHNvbHZlIG15ICpyZWFsKiBwcm9ibGVtLCBh bmQgd2lsbCBiZSBhYmxlIHRvCnByb2dyYW1tYXRpY2FsbHkgdmFsaWRhdGUgYW55IFVTLWJhc2Vk IGFkZHJlc3MuPGJyPgo8YnI+CkFueWJvZHkga25vdyB3aHkgU3F1ZWFrIGlzIGdpdmluZyBtZSBk aWZmZXJlbnQgcmVzdWx0cyB0aGFuIHRoZSB3ZWIKYnJvd3NlcnMgZG8/PGJyPgo8YnI+Ck5ldmlu PGJyPgo8YnI+CjwvYmlnPgo8L2JvZHk+CjwvaHRtbD4K --===============7670088816753387792==-- From brent.vukmer@gmail.com Tue Dec 27 15:20:43 2005 From: Brent Vukmer To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 10:20:42 -0500 Message-ID: <7e2418320512270720q4590aed5we6b37be7bd3000e0@mail.gmail.com> In-Reply-To: <43B0BC2F.4010403@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4564107383590406975==" --===============4564107383590406975== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nevin - Have you watched the HTTP request/response interaction using Ethereal? I find that tool to be a very helpful complement to digging into networking code. --===============4564107383590406975== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 TmV2aW4gLTxicj48YnI+SGF2ZSB5b3Ugd2F0Y2hlZCB0aGUgSFRUUCByZXF1ZXN0L3Jlc3BvbnNl IGludGVyYWN0aW9uIHVzaW5nIEV0aGVyZWFsPyZuYnNwOyBJIGZpbmQgdGhhdCB0b29sIHRvIGJl IGEgdmVyeSBoZWxwZnVsIGNvbXBsZW1lbnQgdG8gZGlnZ2luZyBpbnRvIG5ldHdvcmtpbmcgY29k ZS48YnI+Cg== --===============4564107383590406975==-- From nevin@bountifulbaby.com Tue Dec 27 17:14:49 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 10:14:47 -0700 Message-ID: <43B17687.2030908@bountifulbaby.com> In-Reply-To: <7e2418320512270720q4590aed5we6b37be7bd3000e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2075604281450320844==" --===============2075604281450320844== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Brent Vukmer wrote: > Nevin - > > Have you watched the HTTP request/response interaction using > Ethereal? I find that tool to be a very helpful complement to digging > into networking code. > >------------------------------------------------------------------------ > > > > I'll try it. Unfortunately, I'm Mac based. So, I'll have to dig up another machine somewhere. But I'll give it a go. In the meantime, if anybody else has any other ideas, it would be appreciated. Nevin --===============2075604281450320844== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1J U08tODg1OS0xIiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPgo8L2hlYWQ+Cjxib2R5IGJnY29s b3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPgpCcmVudCBWdWttZXIgd3JvdGU6CjxibG9ja3F1 b3RlCiBjaXRlPSJtaWQ3ZTI0MTgzMjA1MTIyNzA3MjBxNDU5MGFlZDV3ZTZiMzdiZTdiZDMwMDBl MEBtYWlsLmdtYWlsLmNvbSIKIHR5cGU9ImNpdGUiPk5ldmluIC08YnI+CiAgPGJyPgpIYXZlIHlv dSB3YXRjaGVkIHRoZSBIVFRQIHJlcXVlc3QvcmVzcG9uc2UgaW50ZXJhY3Rpb24gdXNpbmcgRXRo ZXJlYWw/Jm5ic3A7CkkgZmluZCB0aGF0IHRvb2wgdG8gYmUgYSB2ZXJ5IGhlbHBmdWwgY29tcGxl bWVudCB0byBkaWdnaW5nIGludG8KbmV0d29ya2luZyBjb2RlLjxicj4KICA8cHJlIHdyYXA9IiI+ CjxociBzaXplPSI0IiB3aWR0aD0iOTAlIj4KCiAgPC9wcmU+CjwvYmxvY2txdW90ZT4KPGJyPgpJ J2xsIHRyeSBpdC4mbmJzcDsgVW5mb3J0dW5hdGVseSwgSSdtIE1hYyBiYXNlZC4mbmJzcDsgU28s IEknbGwgaGF2ZSB0byBkaWcgdXAKYW5vdGhlciBtYWNoaW5lIHNvbWV3aGVyZS4mbmJzcDsgQnV0 IEknbGwgZ2l2ZSBpdCBhIGdvLjxicj4KPGJyPgpJbiB0aGUgbWVhbnRpbWUsIGlmIGFueWJvZHkg ZWxzZSBoYXMgYW55IG90aGVyIGlkZWFzLCBpdCB3b3VsZCBiZQphcHByZWNpYXRlZC48YnI+Cjxi cj4KTmV2aW48YnI+Cjxicj4KPC9ib2R5Pgo8L2h0bWw+Cg== --===============2075604281450320844==-- From bobc@nfldinet.com Tue Dec 27 17:38:18 2005 From: Bob Courchaine To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 11:38:18 -0600 Message-ID: <43B17C0A.2030408@nfldinet.com> In-Reply-To: <43B17687.2030908@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4745916514345866885==" --===============4745916514345866885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nevin Pratt wrote: > Brent Vukmer wrote: >> >> Have you watched the HTTP request/response interaction using >> Ethereal? I find that tool to be a very helpful complement to digging >> into networking code. > I'll try it. Unfortunately, I'm Mac based. So, I'll have to dig up > another machine somewhere. But I'll give it a go. Nevin, try using tcpdump from a Terminal. It comes w/ OS X. You'll have to use sudo to run it as root ("sudo tcpdump"). Bob --===============4745916514345866885==-- From nevin@bountifulbaby.com Tue Dec 27 18:13:03 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 11:13:00 -0700 Message-ID: <43B1842C.7030700@bountifulbaby.com> In-Reply-To: <43B17C0A.2030408@nfldinet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5804773644107840641==" --===============5804773644107840641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bob Courchaine wrote: >Nevin Pratt wrote: > =20 > >>Brent Vukmer wrote: >> =20 >> >>>Have you watched the HTTP request/response interaction using >>>Ethereal? I find that tool to be a very helpful complement to digging >>>into networking code. >>> =20 >>> > > =20 > >>I'll try it. Unfortunately, I'm Mac based. So, I'll have to dig up >>another machine somewhere. But I'll give it a go. >> =20 >> > >Nevin, try using tcpdump from a Terminal. It comes w/ OS X. > >You'll have to use sudo to run it as root ("sudo tcpdump"). > >Bob > > =20 > I tried that. It wasn't particularly helpful. For example, while=20 running tcpdump, when I type the following URL into my (Thunderbird)=20 browser: http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D

6406 Ivy=20 LaneGreenbeltMD

tcpdump gives me the following: > 10:56:05.224754 IP 192.168.0.25.56308 >=20 > utscfwhm01.ut.sprintbbd.net.domain: 26942+ A?=20 > testing.shippingapis.com. (42) > 10:56:05.345274 IP utscfwhm01.ut.sprintbbd.net.domain >=20 > 192.168.0.25.56308: 26942* 1/3/3 A[|domain] > 10:56:05.346627 IP 192.168.0.25.50582 > testing.shippingapis.com.http:=20 > S 1878312729:1878312729(0) win 65535 0,nop,nop,timestamp 1507361664 0> > 10:56:05.414864 IP testing.shippingapis.com.http > 192.168.0.25.50582:=20 > S 2571541148:2571541148(0) ack 1878312730 win 17520 1460,nop,wscale 0,nop,nop,timestamp 0 0> > 10:56:05.414968 IP 192.168.0.25.50582 > testing.shippingapis.com.http:=20 > . ack 1 win 65535 > 10:56:05.415152 IP 192.168.0.25.50582 > testing.shippingapis.com.http:=20 > P 1:723(722) ack 1 win 65535 > 10:56:05.528382 IP testing.shippingapis.com.http > 192.168.0.25.50582:=20 > P 1:101(100) ack 723 win 16798 > 10:56:05.529178 IP testing.shippingapis.com.http > 192.168.0.25.50582:=20 > FP 101:258(157) ack 723 win 16798 > 10:56:05.529229 IP 192.168.0.25.50582 > testing.shippingapis.com.http:=20 > . ack 259 win 65535 > 10:56:05.529436 IP 192.168.0.25.50582 > testing.shippingapis.com.http:=20 > F 723:723(0) ack 259 win 65535 > 10:56:05.599318 IP testing.shippingapis.com.http > 192.168.0.25.50582:=20 > . ack 724 win 16798 Then, in Squeak, when I enter that same URL as an argument to=20 "HTTPClient httpGetDocument:", tcpdump gives me the following: > 11:00:42.637048 IP 192.168.0.25.56324 >=20 > utscfwhm01.ut.sprintbbd.net.domain: 4024+ PTR?=20 > 12.0.0.224.in-addr.arpa. (41) > 11:00:42.693034 IP utscfwhm01.ut.sprintbbd.net.domain >=20 > 192.168.0.25.56324: 4024* 1/3/9 PTR[|domain] > 11:00:43.055624 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > S 849893481:849893481(0) win 65535 0,nop,nop,timestamp 1507362219 0> > 11:00:43.193739 IP testing.shippingapis.com.http > 192.168.0.25.49271:=20 > S 1243403613:1243403613(0) ack 849893482 win 17520 1460,nop,wscale 0,nop,nop,timestamp 0 0> > 11:00:43.193830 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > . ack 1 win 65535 > 11:00:43.555171 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > P 1:366(365) ack 1 win 65535 > 11:00:43.636319 IP testing.shippingapis.com.http > 192.168.0.25.49271:=20 > F 225:225(0) ack 366 win 17155 > 11:00:43.636409 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > . ack 1 win 65535 > 11:00:43.637288 IP testing.shippingapis.com.http > 192.168.0.25.49271:=20 > P 1:225(224) ack 366 win 17155 > 11:00:43.637322 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > . ack 226 win 65535 > 11:00:44.376669 IP 192.168.0.25.49271 > testing.shippingapis.com.http:=20 > R 366:366(0) ack 226 win 65535 As far as I can tell, that doesn't tell me anything about why the=20 Microsoft IIS server at "testing.shippingapis.com" is treating the two=20 requests differently-- why it works fine when my browser is the client,=20 but returns a "400 Bad Request" error when Squeak is the client. Nevin =20 --===============5804773644107840641== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1J U08tODg1OS0xIiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPgo8L2hlYWQ+Cjxib2R5IGJnY29s b3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPgpCb2IgQ291cmNoYWluZSB3cm90ZToKPGJsb2Nr cXVvdGUgY2l0ZT0ibWlkNDNCMTdDMEEuMjAzMDQwOEBuZmxkaW5ldC5jb20iIHR5cGU9ImNpdGUi PgogIDxwcmUgd3JhcD0iIj5OZXZpbiBQcmF0dCB3cm90ZToKICA8L3ByZT4KICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4KICAgIDxwcmUgd3JhcD0iIj5CcmVudCBWdWttZXIgd3JvdGU6CiAgICA8 L3ByZT4KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICA8cHJlIHdyYXA9IiI+SGF2 ZSB5b3Ugd2F0Y2hlZCB0aGUgSFRUUCByZXF1ZXN0L3Jlc3BvbnNlIGludGVyYWN0aW9uIHVzaW5n CkV0aGVyZWFsPyAgSSBmaW5kIHRoYXQgdG9vbCB0byBiZSBhIHZlcnkgaGVscGZ1bCBjb21wbGVt ZW50IHRvIGRpZ2dpbmcKaW50byBuZXR3b3JraW5nIGNvZGUuCiAgICAgIDwvcHJlPgogICAgPC9i bG9ja3F1b3RlPgogIDwvYmxvY2txdW90ZT4KICA8cHJlIHdyYXA9IiI+PCEtLS0tPgogIDwvcHJl PgogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgPHByZSB3cmFwPSIiPkknbGwgdHJ5IGl0 LiAgVW5mb3J0dW5hdGVseSwgSSdtIE1hYyBiYXNlZC4gIFNvLCBJJ2xsIGhhdmUgdG8gZGlnIHVw CmFub3RoZXIgbWFjaGluZSBzb21ld2hlcmUuICBCdXQgSSdsbCBnaXZlIGl0IGEgZ28uCiAgICA8 L3ByZT4KICA8L2Jsb2NrcXVvdGU+CiAgPHByZSB3cmFwPSIiPjwhLS0tLT4KTmV2aW4sIHRyeSB1 c2luZyB0Y3BkdW1wIGZyb20gYSBUZXJtaW5hbC4gSXQgY29tZXMgdy8gT1MgWC4KCllvdSdsbCBo YXZlIHRvIHVzZSBzdWRvIHRvIHJ1biBpdCBhcyByb290ICgic3VkbyB0Y3BkdW1wIikuCgpCb2IK CiAgPC9wcmU+CjwvYmxvY2txdW90ZT4KSSB0cmllZCB0aGF0LiZuYnNwOyBJdCB3YXNuJ3QgcGFy dGljdWxhcmx5IGhlbHBmdWwuJm5ic3A7IEZvciBleGFtcGxlLCB3aGlsZQpydW5uaW5nIHRjcGR1 bXAsIHdoZW4gSSB0eXBlIHRoZSBmb2xsb3dpbmcgVVJMIGludG8gbXkgKFRodW5kZXJiaXJkKQpi cm93c2VyOjxicj4KPGJyPgo8dHQ+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIKIGhy ZWY9Imh0dHA6Ly90ZXN0aW5nLnNoaXBwaW5nYXBpcy5jb20vU2hpcHBpbmdBUElUZXN0LmRsbD9B UEk9VmVyaWZ5JmFtcDtYTUw9Ij5odHRwOi8vdGVzdGluZy5zaGlwcGluZ2FwaXMuY29tL1NoaXBw aW5nQVBJVGVzdC5kbGw/QVBJPVZlcmlmeSZhbXA7WE1MPTwvYT4mbHQ7QWRkcmVzc1ZhbGlkYXRl UmVxdWVzdAomZ3Q7Jmx0O0FkZHJlc3MKSUQ9IjAiJmd0OyZsdDtBZGRyZXNzMSZndDsmbHQ7L0Fk ZHJlc3MxJmd0OyZsdDtBZGRyZXNzMiZndDs2NDA2IEl2eQpMYW5lJmx0Oy9BZGRyZXNzMiZndDsm bHQ7Q2l0eSZndDtHcmVlbmJlbHQmbHQ7L0NpdHkmZ3Q7Jmx0O1N0YXRlJmd0O01EJmx0Oy9TdGF0 ZSZndDsmbHQ7WmlwNSZndDsmbHQ7L1ppcDUmZ3Q7Jmx0O1ppcDQmZ3Q7Jmx0Oy9aaXA0Jmd0OyZs dDsvQWRkcmVzcyZndDsmbHQ7L0FkZHJlc3NWYWxpZGF0ZVJlcXVlc3QmZ3Q7PC90dD48YnI+Cjxi cj4KdGNwZHVtcCBnaXZlcyBtZSB0aGUgZm9sbG93aW5nOjxicj4KPGJyPgo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4xMDo1NjowNS4yMjQ3NTQgSVAgMTkyLjE2OC4wLjI1LjU2MzA4ICZndDsKdXRz Y2Z3aG0wMS51dC5zcHJpbnRiYmQubmV0LmRvbWFpbjombmJzcDsgMjY5NDIrIEE/CnRlc3Rpbmcu c2hpcHBpbmdhcGlzLmNvbS4gKDQyKTxicj4KMTA6NTY6MDUuMzQ1Mjc0IElQIHV0c2Nmd2htMDEu dXQuc3ByaW50YmJkLm5ldC5kb21haW4gJmd0OwoxOTIuMTY4LjAuMjUuNTYzMDg6Jm5ic3A7IDI2 OTQyKiAxLzMvMyBBW3xkb21haW5dPGJyPgoxMDo1NjowNS4zNDY2MjcgSVAgMTkyLjE2OC4wLjI1 LjUwNTgyICZndDsKdGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHA6IFMgMTg3ODMxMjcyOTox ODc4MzEyNzI5KDApIHdpbiA2NTUzNQombHQ7bXNzIDE0NjAsbm9wLHdzY2FsZSAwLG5vcCxub3As dGltZXN0YW1wIDE1MDczNjE2NjQgMCZndDs8YnI+CjEwOjU2OjA1LjQxNDg2NCBJUCB0ZXN0aW5n LnNoaXBwaW5nYXBpcy5jb20uaHR0cCAmZ3Q7CjE5Mi4xNjguMC4yNS41MDU4MjogUyAyNTcxNTQx MTQ4OjI1NzE1NDExNDgoMCkgYWNrIDE4NzgzMTI3MzAgd2luIDE3NTIwCiZsdDttc3MgMTQ2MCxu b3Asd3NjYWxlIDAsbm9wLG5vcCx0aW1lc3RhbXAgMCAwJmd0Ozxicj4KMTA6NTY6MDUuNDE0OTY4 IElQIDE5Mi4xNjguMC4yNS41MDU4MiAmZ3Q7CnRlc3Rpbmcuc2hpcHBpbmdhcGlzLmNvbS5odHRw OiAuIGFjayAxIHdpbiA2NTUzNSAmbHQ7bm9wLG5vcCx0aW1lc3RhbXAKMTUwNzM2MTY2NCAwJmd0 Ozxicj4KMTA6NTY6MDUuNDE1MTUyIElQIDE5Mi4xNjguMC4yNS41MDU4MiAmZ3Q7CnRlc3Rpbmcu c2hpcHBpbmdhcGlzLmNvbS5odHRwOiBQIDE6NzIzKDcyMikgYWNrIDEgd2luIDY1NTM1CiZsdDtu b3Asbm9wLHRpbWVzdGFtcCAxNTA3MzYxNjY0IDAmZ3Q7PGJyPgoxMDo1NjowNS41MjgzODIgSVAg dGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHAgJmd0OwoxOTIuMTY4LjAuMjUuNTA1ODI6IFAg MToxMDEoMTAwKSBhY2sgNzIzIHdpbiAxNjc5OAombHQ7bm9wLG5vcCx0aW1lc3RhbXAgMTEyNTk5 ODE1IDE1MDczNjE2NjQmZ3Q7PGJyPgoxMDo1NjowNS41MjkxNzggSVAgdGVzdGluZy5zaGlwcGlu Z2FwaXMuY29tLmh0dHAgJmd0OwoxOTIuMTY4LjAuMjUuNTA1ODI6IEZQIDEwMToyNTgoMTU3KSBh Y2sgNzIzIHdpbiAxNjc5OAombHQ7bm9wLG5vcCx0aW1lc3RhbXAgMTEyNTk5ODE1IDE1MDczNjE2 NjQmZ3Q7PGJyPgoxMDo1NjowNS41MjkyMjkgSVAgMTkyLjE2OC4wLjI1LjUwNTgyICZndDsKdGVz dGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHA6IC4gYWNrIDI1OSB3aW4gNjU1MzUKJmx0O25vcCxu b3AsdGltZXN0YW1wIDE1MDczNjE2NjQgMTEyNTk5ODE1Jmd0Ozxicj4KMTA6NTY6MDUuNTI5NDM2 IElQIDE5Mi4xNjguMC4yNS41MDU4MiAmZ3Q7CnRlc3Rpbmcuc2hpcHBpbmdhcGlzLmNvbS5odHRw OiBGIDcyMzo3MjMoMCkgYWNrIDI1OSB3aW4gNjU1MzUKJmx0O25vcCxub3AsdGltZXN0YW1wIDE1 MDczNjE2NjQgMTEyNTk5ODE1Jmd0Ozxicj4KMTA6NTY6MDUuNTk5MzE4IElQIHRlc3Rpbmcuc2hp cHBpbmdhcGlzLmNvbS5odHRwICZndDsKMTkyLjE2OC4wLjI1LjUwNTgyOiAuIGFjayA3MjQgd2lu IDE2Nzk4ICZsdDtub3Asbm9wLHRpbWVzdGFtcCAxMTI1OTk4MTYKMTUwNzM2MTY2NCZndDs8YnI+ CjwvYmxvY2txdW90ZT4KPGJyPgpUaGVuLCBpbiBTcXVlYWssIHdoZW4gSSBlbnRlciB0aGF0IHNh bWUgVVJMIGFzIGFuIGFyZ3VtZW50IHRvCiJIVFRQQ2xpZW50IGh0dHBHZXREb2N1bWVudDoiLCB0 Y3BkdW1wIGdpdmVzIG1lIHRoZSBmb2xsb3dpbmc6PGJyPgo8YnI+CjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjExOjAwOjQyLjYzNzA0OCBJUCAxOTIuMTY4LjAuMjUuNTYzMjQgJmd0Owp1dHNjZndo bTAxLnV0LnNwcmludGJiZC5uZXQuZG9tYWluOiZuYnNwOyA0MDI0KyBQVFI/CjEyLjAuMC4yMjQu aW4tYWRkci5hcnBhLiAoNDEpPGJyPgoxMTowMDo0Mi42OTMwMzQgSVAgdXRzY2Z3aG0wMS51dC5z cHJpbnRiYmQubmV0LmRvbWFpbiAmZ3Q7CjE5Mi4xNjguMC4yNS41NjMyNDombmJzcDsgNDAyNCog MS8zLzkgUFRSW3xkb21haW5dPGJyPgoxMTowMDo0My4wNTU2MjQgSVAgMTkyLjE2OC4wLjI1LjQ5 MjcxICZndDsKdGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHA6IFMgODQ5ODkzNDgxOjg0OTg5 MzQ4MSgwKSB3aW4gNjU1MzUKJmx0O21zcyAxNDYwLG5vcCx3c2NhbGUgMCxub3Asbm9wLHRpbWVz dGFtcCAxNTA3MzYyMjE5IDAmZ3Q7PGJyPgoxMTowMDo0My4xOTM3MzkgSVAgdGVzdGluZy5zaGlw cGluZ2FwaXMuY29tLmh0dHAgJmd0OwoxOTIuMTY4LjAuMjUuNDkyNzE6IFMgMTI0MzQwMzYxMzox MjQzNDAzNjEzKDApIGFjayA4NDk4OTM0ODIgd2luIDE3NTIwCiZsdDttc3MgMTQ2MCxub3Asd3Nj YWxlIDAsbm9wLG5vcCx0aW1lc3RhbXAgMCAwJmd0Ozxicj4KMTE6MDA6NDMuMTkzODMwIElQIDE5 Mi4xNjguMC4yNS40OTI3MSAmZ3Q7CnRlc3Rpbmcuc2hpcHBpbmdhcGlzLmNvbS5odHRwOiAuIGFj ayAxIHdpbiA2NTUzNSAmbHQ7bm9wLG5vcCx0aW1lc3RhbXAKMTUwNzM2MjIyMCAwJmd0Ozxicj4K MTE6MDA6NDMuNTU1MTcxIElQIDE5Mi4xNjguMC4yNS40OTI3MSAmZ3Q7CnRlc3Rpbmcuc2hpcHBp bmdhcGlzLmNvbS5odHRwOiBQIDE6MzY2KDM2NSkgYWNrIDEgd2luIDY1NTM1CiZsdDtub3Asbm9w LHRpbWVzdGFtcCAxNTA3MzYyMjIwIDAmZ3Q7PGJyPgoxMTowMDo0My42MzYzMTkgSVAgdGVzdGlu Zy5zaGlwcGluZ2FwaXMuY29tLmh0dHAgJmd0OwoxOTIuMTY4LjAuMjUuNDkyNzE6IEYgMjI1OjIy NSgwKSBhY2sgMzY2IHdpbiAxNzE1NQombHQ7bm9wLG5vcCx0aW1lc3RhbXAgMTEyNTg1MTYxIDE1 MDczNjIyMjAmZ3Q7PGJyPgoxMTowMDo0My42MzY0MDkgSVAgMTkyLjE2OC4wLjI1LjQ5MjcxICZn dDsKdGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHA6IC4gYWNrIDEgd2luIDY1NTM1ICZsdDtu b3Asbm9wLHRpbWVzdGFtcAoxNTA3MzYyMjIwIDAmZ3Q7PGJyPgoxMTowMDo0My42MzcyODggSVAg dGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHAgJmd0OwoxOTIuMTY4LjAuMjUuNDkyNzE6IFAg MToyMjUoMjI0KSBhY2sgMzY2IHdpbiAxNzE1NQombHQ7bm9wLG5vcCx0aW1lc3RhbXAgMTEyNTg1 MTYxIDE1MDczNjIyMjAmZ3Q7PGJyPgoxMTowMDo0My42MzczMjIgSVAgMTkyLjE2OC4wLjI1LjQ5 MjcxICZndDsKdGVzdGluZy5zaGlwcGluZ2FwaXMuY29tLmh0dHA6IC4gYWNrIDIyNiB3aW4gNjU1 MzUKJmx0O25vcCxub3AsdGltZXN0YW1wIDE1MDczNjIyMjAgMTEyNTg1MTYxJmd0Ozxicj4KMTE6 MDA6NDQuMzc2NjY5IElQIDE5Mi4xNjguMC4yNS40OTI3MSAmZ3Q7CnRlc3Rpbmcuc2hpcHBpbmdh cGlzLmNvbS5odHRwOiBSIDM2NjozNjYoMCkgYWNrIDIyNiB3aW4gNjU1MzU8YnI+CjwvYmxvY2tx dW90ZT4KPGJyPgpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhhdCBkb2Vzbid0IHRlbGwgbWUgYW55 dGhpbmcgYWJvdXQgd2h5IHRoZQpNaWNyb3NvZnQgSUlTIHNlcnZlciBhdCAidGVzdGluZy5zaGlw cGluZ2FwaXMuY29tIiBpcyB0cmVhdGluZyB0aGUgdHdvCnJlcXVlc3RzIGRpZmZlcmVudGx5LS0g d2h5IGl0IHdvcmtzIGZpbmUgd2hlbiBteSBicm93c2VyIGlzIHRoZSBjbGllbnQsCmJ1dCByZXR1 cm5zIGEgIjQwMCBCYWQgUmVxdWVzdCIgZXJyb3Igd2hlbiBTcXVlYWsgaXMgdGhlIGNsaWVudC48 YnI+Cjxicj4KTmV2aW48YnI+Cjxicj4KPGJyPgombmJzcDsmbmJzcDsgPGJyPgo8L2JvZHk+Cjwv aHRtbD4K --===============5804773644107840641==-- From m.rueger@acm.org Tue Dec 27 18:30:48 2005 From: Michael Rueger To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 19:30:42 +0100 Message-ID: <43B18852.7000308@acm.org> In-Reply-To: <43B1842C.7030700@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5351526900768907949==" --===============5351526900768907949== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nevin Pratt wrote: > As far as I can tell, that doesn't tell me anything about why the > Microsoft IIS server at "testing.shippingapis.com" is treating the two > requests differently-- why it works fine when my browser is the client, > but returns a "400 Bad Request" error when Squeak is the client. You will need to look at what the browsers are sending. One way would be to open a listening socket in squeak on port 80 and then connect to it with your browser with a url like http://localhost/ShippingAPITest.dll?API=Verify&XML= To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 12:57:01 -0800 Message-ID: In-Reply-To: <43B18852.7000308@acm.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2434162854357897677==" --===============2434162854357897677== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I think if you look at the man page for TCPDUMP you'll find it can dump the contents of the tcp packets, versus the headers, then you can see exactly what the browser is sending and getting. On 27-Dec-05, at 10:30 AM, Michael Rueger wrote: > Nevin Pratt wrote: > >> As far as I can tell, that doesn't tell me anything about why the >> Microsoft IIS server at "testing.shippingapis.com" is treating the >> two requests differently-- why it works fine when my browser is >> the client, but returns a "400 Bad Request" error when Squeak is >> the client. > > You will need to look at what the browsers are sending. > One way would be to open a listening socket in squeak on port 80 > and then connect to it with your browser with a url like > http://localhost/ShippingAPITest.dll?API=Verify&XML= > Or even before that look at how squeak actually parses the URL. > > Michael > -- ======================================================================== === John M. McIntosh 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === --===============2434162854357897677==-- From mailinglist.fischer@bluewin.ch Tue Dec 27 22:00:26 2005 From: Alain Fischer To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 23:00:23 +0100 Message-ID: <3c23d827b613ee2f3379877572a53db2@bluewin.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7275729036915376846==" --===============7275729036915376846== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Or you can use tcpflow: http://www.entropy.ch/software/macosx/#tcpflow and you can see the content of tcp packet. I am using the 0.21 package and it work well on 10.3 and 10.4 Don't forget the -c flag to see content on the console. Alain Le 27 déc. 05, à 21:57, John M McIntosh a écrit : > I think if you look at the man page for TCPDUMP you'll find it can > dump the contents of the tcp packets, versus the headers, then you can > see exactly what the browser is > sending and getting. > > On 27-Dec-05, at 10:30 AM, Michael Rueger wrote: > >> Nevin Pratt wrote: >> >>> As far as I can tell, that doesn't tell me anything about why the >>> Microsoft IIS server at "testing.shippingapis.com" is treating the >>> two requests differently-- why it works fine when my browser is the >>> client, but returns a "400 Bad Request" error when Squeak is the >>> client. >> >> You will need to look at what the browsers are sending. >> One way would be to open a listening socket in squeak on port 80 and >> then connect to it with your browser with a url like >> http://localhost/ShippingAPITest.dll?API=Verify&XML=> >> Or even before that look at how squeak actually parses the URL. >> >> Michael >> > > -- > ======================================================================= > ==== > John M. McIntosh 1-800-477-2659 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > ======================================================================= > ==== > > --===============7275729036915376846==-- From yanni@rogers.com Wed Dec 28 03:41:04 2005 From: Yanni Chiu To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 22:40:51 -0500 Message-ID: In-Reply-To: <43B1842C.7030700@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4120559760077687396==" --===============4120559760077687396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nevin Pratt wrote: > http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D >

6406 Ivy=20 > LaneGreenbeltMD

Yesterday, I tried this URL in Firefox running on XP Home. It kept coming back with a dialog to save or open "ShippingAPITest.dll". I chose not to save it, and assumed that maybe someone else would have an answer for you. Anyhow, is it possible that you have this .dll already on your system, but Squeak has no way to make use of it? --=20 Yanni Chiu --===============4120559760077687396==-- From nevin@bountifulbaby.com Wed Dec 28 04:01:13 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Tue, 27 Dec 2005 21:01:11 -0700 Message-ID: <43B20E07.1070605@bountifulbaby.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2604828572861337306==" --===============2604828572861337306== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yanni Chiu wrote: > Nevin Pratt wrote: > >> http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D> >

6406 Ivy=20 >> LaneGreenbeltMD<= /Zip4>

=20 >> > > > Yesterday, I tried this URL in Firefox running on XP Home. > It kept coming back with a dialog to save or open > "ShippingAPITest.dll". I chose not to save it, > and assumed that maybe someone else would have > an answer for you. Anyhow, is it possible that > you have this .dll already on your system, but > Squeak has no way to make use of it? > No. Save it. It is a text file. Look at the text. That is the response=20 text, in the file that you are saving. I don't understand web protocols well enough to know why the response is=20 coming back via a file named "ShippingAPIText.dll". But, the file=20 actually contains the text response that I am looking for. How do I get Squeak to do this? Thanks, Yanni! Nevin --===============2604828572861337306==-- From bobc@nfldinet.com Wed Dec 28 17:42:59 2005 From: Bob Courchaine To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 11:42:52 -0600 Message-ID: <43B2CE9C.3090400@nfldinet.com> In-Reply-To: <43B20E07.1070605@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4162610479288889950==" --===============4162610479288889950== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I didn't dig very far but it seems Firefox's issue is that doesn't know what to do w/ a ".dll" file. I downloaded the response, changed the extension to .xml and Firefox opened it formatted as XML, complaining, "This XML file does not appear to have any style information associated with it. The document tree is shown below." Just for fun, I added a prolog declaring the document as XML (). Then I changed the extension back to .dll and tried to Open the File in Firefox. It still didn't know how to handle it, asking to download it again. So in this case the issue is with the client. >From working w/ web services, I'd not expect to display this in a web browser. I'd save it to the filesystem and parse, etc it from there. Just because IE displays it w/o complaining doesn't mean it's typical and expected practice. I deleted your original question, Nevin, so I'm not sure what you're trying to do. But I'd suggest it's not the GET mechanism that's the problem, it's the handling of the response. Bob Nevin Pratt wrote: > Yanni Chiu wrote: >=20 >> Nevin Pratt wrote: >> >>> http://testing.shippingapis.com/ShippingAPITest.dll?API=3DVerify&XML=3D>> >

6406 Ivy >>> LaneGreenbeltMD=

>>> >> >> >> >> Yesterday, I tried this URL in Firefox running on XP Home. >> It kept coming back with a dialog to save or open >> "ShippingAPITest.dll". I chose not to save it, >> and assumed that maybe someone else would have >> an answer for you. Anyhow, is it possible that >> you have this .dll already on your system, but >> Squeak has no way to make use of it? >> >=20 > No. >=20 > Save it. It is a text file. Look at the text. That is the response > text, in the file that you are saving. >=20 > I don't understand web protocols well enough to know why the response is > coming back via a file named "ShippingAPIText.dll". But, the file > actually contains the text response that I am looking for. >=20 > How do I get Squeak to do this? >=20 > Thanks, Yanni! >=20 > Nevin >=20 >=20 --===============4162610479288889950==-- From nevin@bountifulbaby.com Wed Dec 28 18:02:45 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 11:02:44 -0700 Message-ID: <43B2D344.1030001@bountifulbaby.com> In-Reply-To: <43B2CE9C.3090400@nfldinet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0092197277009098094==" --===============0092197277009098094== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Bob Courchaine wrote: >I didn't dig very far but it seems Firefox's issue is that doesn't know >what to do w/ a ".dll" file. > >I downloaded the response, changed the extension to .xml and Firefox >opened it formatted as XML, complaining, "This XML file does not appear >to have any style information associated with it. The document tree is >shown below." > >Just for fun, I added a prolog declaring the document as XML (version = "1.0"?>). Then I changed the extension back to .dll and tried >to Open the File in Firefox. It still didn't know how to handle it, >asking to download it again. > > Actually, I don't care to open the file in Firefox, or any other browser, and I don't care about files. I just want to hit that URL in Squeak, and get the response into Squeak. If you put the URL in Firefox, it is correct that Firefox thinks it is downloading a file. But the file that it downloads is a text file that contains the response. I want to retrieve that response, via the URL, totally inside of Squeak, without dealing with files. It's that simple. Or so I would think. Nevin --===============0092197277009098094==-- From tblanchard@mac.com Wed Dec 28 18:29:51 2005 From: Todd Blanchard To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 10:29:54 -0800 Message-ID: <319FDB5C-7DEE-4476-9F55-E12F8987F699@mac.com> In-Reply-To: <43B2D344.1030001@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4176636025687929267==" --===============4176636025687929267== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I haven't been using HttpClient, but I've been fetching documents using something like 'http://www.foo.com' asUrl retrieveContents which gets you an instance of MimeDocument. I don't know if that helps you. On Dec 28, 2005, at 10:02 AM, Nevin Pratt wrote: > Bob Courchaine wrote: > >> I didn't dig very far but it seems Firefox's issue is that doesn't >> know >> what to do w/ a ".dll" file. >> >> I downloaded the response, changed the extension to .xml and Firefox >> opened it formatted as XML, complaining, "This XML file does not >> appear >> to have any style information associated with it. The document >> tree is >> shown below." >> >> Just for fun, I added a prolog declaring the document as XML (> version = "1.0"?>). Then I changed the extension back to .dll and >> tried >> to Open the File in Firefox. It still didn't know how to handle it, >> asking to download it again. >> > > Actually, I don't care to open the file in Firefox, or any other > browser, and I don't care about files. > I just want to hit that URL in Squeak, and get the response into > Squeak. > > If you put the URL in Firefox, it is correct that Firefox thinks it > is downloading a file. But the file that it downloads is a text > file that contains the response. > > I want to retrieve that response, via the URL, totally inside of > Squeak, without dealing with files. It's that simple. > > Or so I would think. > > Nevin > > --===============4176636025687929267==-- From bobc@nfldinet.com Wed Dec 28 18:37:42 2005 From: Bob Courchaine To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 12:37:40 -0600 Message-ID: <43B2DB74.3040004@nfldinet.com> In-Reply-To: <43B2D344.1030001@bountifulbaby.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2310934957457070249==" --===============2310934957457070249== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nevin Pratt wrote: > I want to retrieve that response, via the URL, totally inside of Squeak, > without dealing with files. It's that simple. ? I thought your issue was w/ a client you were trying to use, like Celeste. In a Workspace, Inspect " asUrl retrieveContents". A MIMEDocument is returned. Look at the "Contents" and you'll see your error message. --===============2310934957457070249==-- From hmm@heeg.de Wed Dec 28 19:00:15 2005 From: Hans-Martin Mosner To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 20:00:10 +0100 Message-ID: <43B2E0BA.4090009@heeg.de> In-Reply-To: <43B2DB74.3040004@nfldinet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5581342215364344410==" --===============5581342215364344410== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bob Courchaine wrote: >Nevin Pratt wrote: > =20 > >>I want to retrieve that response, via the URL, totally inside of Squeak, >>without dealing with files. It's that simple. >> =20 >> > >? > >I thought your issue was w/ a client you were trying to use, like Celeste. > >In a Workspace, Inspect " asUrl retrieveContents". > >A MIMEDocument is returned. Look at the "Contents" and you'll see your >error message. > > > > =20 > But that's the original, wrong, error message. The problem is that your request is not properly URL-encoded. The=20 easiest way to achieve this (which is also much easier to use=20 programmatically given an XML request string) looks like this: HTTPSocket httpGetDocument: 'http://testing.shippingapis.com/ShippingAPITest.dll' args: ({'API' -> #('Verify'). 'XML' -> #('6406 Ivy=20 LaneGreenbeltMD') } as: Dictionary) accept: 'text/xml' Note that the dictionary values must be arrays of strings, not simple=20 strings. This is a little awkward, but it's how the class is implemented. I've tested it, it works. Cheers, Hans-Martin --===============5581342215364344410==-- From nevin@bountifulbaby.com Wed Dec 28 19:36:14 2005 From: Nevin Pratt To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak Http GET broken? Date: Wed, 28 Dec 2005 12:36:13 -0700 Message-ID: <43B2E92D.8020707@bountifulbaby.com> In-Reply-To: <43B2E0BA.4090009@heeg.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0096614012596782322==" --===============0096614012596782322== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> >> > But that's the original, wrong, error message. > The problem is that your request is not properly URL-encoded. The=20 > easiest way to achieve this (which is also much easier to use=20 > programmatically given an XML request string) looks like this: > > HTTPSocket > httpGetDocument: 'http://testing.shippingapis.com/ShippingAPITest.dll' > args: ({'API' -> #('Verify'). > 'XML' -> #(' ID=3D"0">6406 Ivy=20 > LaneGreenbeltMD')=20 > > } as: Dictionary) > accept: 'text/xml' > > Note that the dictionary values must be arrays of strings, not simple=20 > strings. This is a little awkward, but it's how the class is implemented. > I've tested it, it works. > > Cheers, > Hans-Martin > Your code works. Thanks, Hans! Also, your comment about using "asUrl retrieveContents" producing the=20 wrong results is spot on. Your code is what was needed. Your code lets=20 me use the USPS Web Tools API, to do address validation and more. If anybody else wants to know more about doing this, I've pasted an=20 email from USPS below, and it gives further details. In the email, I've=20 replaced my true Web Tools User ID with x's, though, for obvious=20 reasons. You would obviously have to contact USPS yourself to get your=20 own user ID. Thanks, everyone! Nevin >Thank you for registering for the U. S. Postal Service's Web Tools Applicati= on Program Interfaces (APIs). We are providing you with a User ID that serve= s multiple purposes, as explained below. > > >Your Web Tools User ID is: xxxxxxxxxxxx > > >The latest versions of the technical documentation, including the Administra= tive Guide, are available from USPS.com at: www.usps.com/webtools. They pro= vide documentation and sample code for implementing our APIs. This documenta= tion is in PDF and HTML format. In order to open and view this document in P= DF you must have Adobe Acrobat Reader installed on your system. You may down= load this software, at no cost, from http://www.adobe.com/products/acrobat/re= adstep2.html. > >IMPORTANT NOTE: The current documentation refers to a password. Please ign= ore all references to password in the documentation. Password is no longer u= sed or required. > >Your Web Tools User ID to integrate USPS Web Tools is provided above. The Us= er ID is used for testing your implementation of the API(s). With this ID, y= ou may begin sending calls to the test server. The address to the test serve= r is: testing.shippingapis.com and the path is /ShippingAPITest.dll. Use th= is information in combination with your User ID and your XML string to send a= request to the USPS servers. For more details, refer to the programming gui= des (located at >www.usps.com/webtools) for the specific API you are integrating. > >A sample test request would look like: "http://testing.shippingapis.com/Ship= pingAPITest.dll?API=3D[API_Name]&XML=3D >[XML_String_containing_User_ID]" > >When you have completed your testing, email the USPS Internet Customer Care = Center (ICCC). They will switch your profile to allow you access to the prod= uction server and will provide you with the production URL. > >The ICCC is staffed from 7:00AM to 11:00PM Eastern Time. > > E-mail: icustomercare(a)usps.com > Telephone: 1-800-344-7779=20 > > > IMPORTANT NOTICE REGARDING USER ID > > >The Web Tools User ID provided is for you and your company to use when reque= sting data via the Internet from the U.S. Postal Service API servers. This u= nique User ID cannot be shared with others outside your organization, nor is = it to be packaged and distributed or sold to other individuals, businesses or= e-commerce web site entities. As per the Terms and Conditions of Use Agreem= ent you agreed to during the Web Tools registration process, you are responsi= ble to maintain the confidentiality of your User ID as specified. You may no= t package any APIs with your User ID for resale or distribution to others. T= he U.S. Postal Service does not prohibit the reuse and/or distribution of the= API documentation (User's Guide) with sample code in order to generate aware= ness, encourage use or provide ease-of-use to customers or affiliates.=20 > >Warning - If the U.S. Postal Service discovers use of the same User ID from = more than one web site, all users will be subject to loss of access to the US= PS production server and/or termination of the licenses granted under the Ter= ms and Conditions of Use. For more information regarding the USPS Web Tools = User ID policy, or for questions regarding distribution of documentation, sen= d email to icustomercare(a)usps.com. > >Thank you for helping the U.S. Postal Service provide new services to our sh= ipping customers. > >Sincerely, > >The Internet Shipping Solutions Team > >USPS Internet Customer Care Center >icustomercare(a)usps.gov >7:00AM - 11:00PM EST > =20 > --===============0096614012596782322==--