From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5ab04e072064bfe53f47b5a785bc41ec@quanstro.net> References: <3587eb7837ae411c3c512564d9997e1c@smgl.fr.eu.org> <5ab04e072064bfe53f47b5a785bc41ec@quanstro.net> Date: Fri, 27 Mar 2009 08:52:48 -0400 Message-ID: <9ab217670903270552o64036bc6l822ca1f6e73ec82f@mail.gmail.com> From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] another webfs question Topicbox-Message-UUID: cb15642e-ead4-11e9-9d60-3106f5b1d025 2009/3/27 erik quanstrom : >> It seems I'm hitting this error when sending some GET requests: >> >> In /sys/src/cmd/webfs/url.c: >> >> =A0 =A0 =A0 if(strstr(url, "%00")){ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 werrstr("escaped NUL in URI"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1; >> =A0 =A0 =A0 } >> >> I haven't fully understood the comment above, especially if it is agains= t >> the RFC to have an escaped NUL in an url, but this can actually happen, >> at least with queries to a bittorrent tracker. For example when specifyi= ng >> the info hash of a specific torrent when sending a scrape request: >> >> http://bttracker.debian.org:6969/scrape?info_hash=3D%F1%AE%D2%E5%15%A0%B= D%F1%41%54%9D%44%00%47%AB%97%81%2B%69%16 >> (13th char in the info hash is a NUL) >> >> I get a reply to that one both with wget on linux or hget on plan 9, >> while webfs gives the error from the code above. >> >> So is it webfs that needs fixing for that case, or are the other tools >> breaking some RFC with that? > > rfc2396 doesn't mention any restrictions; %00 is legal. Yeah, there aren't any. That's the point of URL encoding; NULL bytes are as acceptable as any other, and your client should be able to handle them -- so I think that webfs check is just bogus. It should just encode it as a \0 and pass it through. --dho > - erik > >