From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.sdf.org ([205.166.94.20]) by ewsd; Fri Jan 3 16:35:17 EST 2020 Received: from [IPv6:2607:fb90:a232:4266:384e:f9e1:eee6:ad7a] ([172.58.142.210]) (authenticated (0 bits)) by mx.sdf.org (8.15.2/8.14.5) with ESMTPSA id 003LZAIQ022654 (using TLSv1.2 with cipher AES128-GCM-SHA256 (128 bits) verified NO); Fri, 3 Jan 2020 21:35:12 GMT Date: Fri, 03 Jan 2020 15:35:06 -0600 User-Agent: K-9 Mail for Android In-Reply-To: <7F4E839FF68583BCBBB0A6D00D3AA358@eigenstate.org> References: <7F4E839FF68583BCBBB0A6D00D3AA358@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress) To: ori@eigenstate.org, 9front@9front.org, jamos@oboj.net From: Kyle Nusbaum Message-ID: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: map/reduce-based HTTP dependency property controller On January 3, 2020 3:01:30 PM CST, ori@eigenstate=2Eorg wrote: >> A shared repo would be nice=2E=20 >>=20 >> My attempt at using webfs has hit a snag, which is that webfs >> does not expose the http response header in any way, as far >> as I can tell=2E I have it partially working in that it is >> getting and returning webpage data, but netsurf wants the >> full response header=2E=20 >>=20 >> I think webfs is not the right solution for this=2E It is not >> the general-purpose http service I thought it was=2E For this >> purpose, it has several issues=2E It provides no access to the >> raw header bytes=2E We could still use it as a hacky solution >> if we could reassemble the http header, but webfs mangles >> header names when creating the header files and leaves out >> cookies=2E=20 > >If we want it to handle cookies uniformly, integrate with factotum, >use devtls, and generally fit into 9front, we definitely want >to use webfs=2E It should be sufficiently general purpose for >our needs=2E > >Is there a reason that tearing out the header parsing code in >netsurf and pointing it to webfs and webcookies wouldn't work? I would imagine that should work=2E However, I haven't dug into the netsur= f internals=2E The fetcher interface seems to be provided for adding ways t= o pull web pages=2E Circumventing that is probably necessary for good integ= ration into 9front, but I'm not sure how much work that is=2E I'll try and = see how fetcher is used and see if it can be replaced=2E I'm not sure what = upstream would think of it=2E Upstream accepting our code is obviously not = totally necessary, but it would be nice=2E >I'd resist it, but if it's absolutely needed, we can also probably >add a 'rawheader' file to webfs=2E I considered this, but it feels like going the wrong direction=2E I don't = think I want to suggest mucking up our clean interfaces because a port does= n't play nicely with them=2E >> However, since netsurf seems to do all the parsing of the >> response except separating header from body, and delivers >> the request URL and post data in pre-packaged form, I think >> it's probably easier to just use a raw /net/tcp connection=2E >>=20 I think for now I'm going to try and use the fetcher interface with a tcp = socket, just to get something working=2E That might allow us to use http at= least and work on other parts of the browser while we look at replacing th= e fetcher with webfs=2E -- Kyle