[9fans] another webfs question

[9fans] another webfs question

[Mathieu]

Hi all,

It seems I'm hitting this error when sending some GET requests:

In /sys/src/cmd/webfs/url.c:

	if(strstr(url, "%00")){
		werrstr("escaped NUL in URI");
		return -1;
	}

I haven't fully understood the comment above, especially if it is against
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 specifying
the info hash of a specific torrent when sending a scrape request:

http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%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?

Cheers,
Mathieu

Re: [9fans] another webfs question

[erik quanstrom]

> It seems I'm hitting this error when sending some GET requests:
>
> In /sys/src/cmd/webfs/url.c:
>
> 	if(strstr(url, "%00")){
> 		werrstr("escaped NUL in URI");
> 		return -1;
> 	}
>
> I haven't fully understood the comment above, especially if it is against
> 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 specifying
> the info hash of a specific torrent when sending a scrape request:
>
> http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%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.

- erik

Re: [9fans] another webfs question

[Devon H. O'Dell]

2009/3/27 erik quanstrom <quanstro@quanstro.net>:
>> It seems I'm hitting this error when sending some GET requests:
>>
>> In /sys/src/cmd/webfs/url.c:
>>
>>       if(strstr(url, "%00")){
>>               werrstr("escaped NUL in URI");
>>               return -1;
>>       }
>>
>> I haven't fully understood the comment above, especially if it is against
>> 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 specifying
>> the info hash of a specific torrent when sending a scrape request:
>>
>> http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%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
>
>

Re: [9fans] another webfs question

[Mathieu Lonjaret]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Ok, thanks to both. In the meanwhile, mjl pointed me to
http://www.ietf.org/rfc/rfc3986.txt, sect. 7.3, where this can found:
"Note, however, that the "%00" percent-encoding
(NUL) may require special handling and should be rejected if the
application is not expecting to receive raw data within a component."

This apparently could be the reason behind the current behaviour of webfs.

I'll try and fix that in webfs unless somebody beats me to it (please
do! ;) ).

Cheers,
Mathieu

[-- Attachment #2: Type: message/rfc822, Size: 5153 bytes --]

From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] another webfs question
Date: Fri, 27 Mar 2009 08:52:48 -0400
Message-ID: <9ab217670903270552o64036bc6l822ca1f6e73ec82f@mail.gmail.com>

2009/3/27 erik quanstrom <quanstro@quanstro.net>:
>> It seems I'm hitting this error when sending some GET requests:
>>
>> In /sys/src/cmd/webfs/url.c:
>>
>>       if(strstr(url, "%00")){
>>               werrstr("escaped NUL in URI");
>>               return -1;
>>       }
>>
>> I haven't fully understood the comment above, especially if it is against
>> 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 specifying
>> the info hash of a specific torrent when sending a scrape request:
>>
>> http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%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
>
>

Re: [9fans] another webfs question

[erik quanstrom]

> 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.

(you do mean %00 should result in a byte with value 0, not
two bytes (in c notation) '\\' and '0', right?)

assuming that every application that uses webfs is prepared
to handle a null byte in the middle of a string.  what webfs does
— complaining loudly — is much preferrable to programs misbehaving
silently.  since it's quite likely that plan 9 applications are not
going to properly deal with a null in a string, it's probablly
a good implementation strategy unless you're willing to test
all the programs that use webfs to make sure that this case
is properly handled.

- erik

Re: [9fans] another webfs question

[Devon H. O'Dell]

2009/3/27 erik quanstrom <quanstro@coraid.com>:
>> 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.
>
> (you do mean %00 should result in a byte with value 0, not
> two bytes (in c notation) '\\' and '0', right?)

Yes, I meant '\0'.

> assuming that every application that uses webfs is prepared
> to handle a null byte in the middle of a string.  what webfs does
> — complaining loudly — is much preferrable to programs misbehaving
> silently.  since it's quite likely that plan 9 applications are not
> going to properly deal with a null in a string, it's probablly
> a good implementation strategy unless you're willing to test
> all the programs that use webfs to make sure that this case
> is properly handled.

Ok, but then valid applications such as this one can't use webfs. I
think something needing this could solve the issue by having the
application import webfs into its own namespace, and then sending some
sort of ctl command telling it to set an option to allow null bytes.

--dho

> - erik
>
>

Re: [9fans] another webfs question

[erik quanstrom]

> > assuming that every application that uses webfs is prepared
> > to handle a null byte in the middle of a string.  what webfs does
> > — complaining loudly — is much preferrable to programs misbehaving
> > silently.  since it's quite likely that plan 9 applications are not
> > going to properly deal with a null in a string, it's probablly
> > a good implementation strategy unless you're willing to test
> > all the programs that use webfs to make sure that this case
> > is properly handled.
>
> Ok, but then valid applications such as this one can't use webfs. I
> think something needing this could solve the issue by having the
> application import webfs into its own namespace, and then sending some
> sort of ctl command telling it to set an option to allow null bytes.

read to the end:
> > unless you're willing to test
> > all the programs that use webfs to make sure that this case
> > is properly handled.

i think it would be a bad idea to add a control swizzle bit
to avoid testing.  testing is not that hard.

grep webfs `{find /sys/src  /rc/bin |grep '\.[chy]$'} | grep -v /webfs/
/sys/src/cmd/webcookies.c: * Cookie file system.  Allows hget and multiple webfs's to collaborate.
/sys/src/cmd/webfsget.c:/* Example of how to use webfs */
/sys/src/cmd/webfsget.c:	fprint(2, "usage: webfsget [-b baseurl] [-m mtpt] [-p postbody] url\n");

you can search contrib, too.  i'm sure that abaco falls on
its face when confronted with a 0 in a url.

- erik

[9fans] porting sam

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

I figure I'm not the only person on this list who would find a newer copy of sam for Windows useful...
I know there's acme-sac, but I still find myself using the 9pm version of sam for remote connections and such.

So, I've been working on and off trying to get sam from plan9port going on Windows.  Currently, I'm using the Inferno hosted environment to do the port.  That may or may not have been a good idea.  I'm now stuck at the function bootterm, in io.c.  Code below.  I'm stuck at the point where sam forks (or proc's) to launch samterm, since Windows provides neither.  emu uses Windows' CreateThread in it's kproc code.  I'm wondering what the best approach here would be, but in the style of some of the other ported Inferno tools, I'm leaning toward implementing the required functions in a "Nt.c" file and building it in.  Using libkern and a few other bits from draterm might work too...

Thanks!
-Ben


void
bootterm(char *machine, char **argv)
{
    int ph2t[2], pt2h[2];

    if(machine){
        dup(remotefd0, 0);
        dup(remotefd1, 1);
        close(remotefd0);
        close(remotefd1);
        argv[0] = "samterm";
        execvp(samterm, argv);
        fprint(2, "can't exec %s: %r\n", samterm);
        _exits("damn");
    }
    if(pipe(ph2t)==-1 || pipe(pt2h)==-1)
        panic("pipe");
    switch(fork()){
    case 0:
        dup(ph2t[0], 0);
        dup(pt2h[1], 1);
        close(ph2t[0]);
        close(ph2t[1]);
        close(pt2h[0]);
        close(pt2h[1]);
        argv[0] = "samterm";
        execvp(samterm, argv);
        fprint(2, "can't exec: ");
        perror(samterm);
        _exits("damn");
    case -1:
        panic("can't fork samterm");
    }
    dup(pt2h[0], 0);
    dup(ph2t[1], 1);
    close(ph2t[0]);
    close(ph2t[1]);
    close(pt2h[0]);
    close(pt2h[1]);
}


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3424 bytes --]

Re: [9fans] porting sam

[Skip Tavakkolian]

> I figure I'm not the only person on this list who would find a newer copy of sam for Windows useful...

i do too.  hoping to get 9vx/win32.

are you looking for CreateProcess and CreatePipe (win32 api's) or trying to
figure out how to do 'sam -r' for a standalone win32 app?

Re: [9fans] porting sam

[Michael Teichgräber]

Hi,

there is now a basically working port of the editor
sam from current plan9port available for Windows:
	http://ib.wmipf.de/pf9/sam.zip (*).

Most parts of the editor are working, including remote
functionality, or executing local commands.
The port is based on various libraries and
programs from p9p that have been adapted to run on
Windows, compiled with the MinGW compiler. Thanks
to Ben for testing the early versions.

Michael

*) sha1sum: 09c06199bba2aa63f7e8c59d70525e50dc378a93