From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 0C92F77D0D for ; Fri, 1 Jan 2016 06:46:30 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id f206so113793801wmf.0 for ; Fri, 01 Jan 2016 06:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a91i0Mwt/itScNDlhiY/rjYAU8fpp3OlkD48HNJNxqk=; b=BeBwblyybM1dP3Hvc8cjALk0+T5qJt22URvLfAuc1ebkQoPoSmMetziueCNKAMiUPt bPEoB7ywZUc26u+IRQdZBB5N672cXH1wIRdS5ShZ8zcGP9tOMzvzRw9e8byT4fTYe3yC eElI+wgca4WUviVXRu5f1fG5trEoAEJRY6rAeFaNLyI2tQk6pAsjfQoG42iYIKEoydIS jz5gVEiuvr0DsUmxqGAmhUEIghfwIPmJ0g1cH0GiH5BtwxFNXcPBgBr0XCjdyI6aR0yW /aM++8u0zWKXR41KHL8PvwKKloYv6uS8pZpi3iBLhbvrCbNbQHtUQGKXSWCEeydEyM8E AMSg== X-Received: by 10.28.6.201 with SMTP id 192mr73084737wmg.0.1451659619400; Fri, 01 Jan 2016 06:46:59 -0800 (PST) Received: from 122oven.adamthompson.me.uk (c.2.2.f.4.7.e.f.f.f.d.1.4.2.2.0.2.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9042:224:1dff:fe74:f22c]) by smtp.gmail.com with ESMTPSA id yy8sm49199967wjc.13.2016.01.01.06.46.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 06:46:58 -0800 (PST) Date: Fri, 1 Jan 2016 14:46:57 +0000 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20160101144657.GC24842@122oven.adamthompson.me.uk> References: <20151130170044.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <20151130170044.eklhad@comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [Edbrowse-dev] Messages to and from edbrowse-curl X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 14:46:30 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A few thoughts: On Wed, Dec 30, 2015 at 05:00:44PM -0500, Karl Dahlke wrote: > * Update a runtime parameter. > These are the commands like vs sr fmp fma hr that influence internet fetc= hes. > We changed the variable in edbrowse, > this is a message to change the same variable in edbrowse-curl. > Response:ack - if a response is even required. > There's some question of whether these changes are system wide, > which would be the easiest to implement. > type vs in any running instance of edbrowse and we are not verifying ssl = for any > of the running edbrowse programs, because edbrowse-curl isn't doing that,= or, > edbrowse-curl maintains instances of these variables for each connected e= dbrowse. > I really don't know the answer to this and don't have a strong opinion on= it. I'm thinking probably that each user would need their own edbrowse-curl, and that within each edbrowse-curl we'd keep track of the individual instan= ces of edbrowse connected to it. This handles a bunch of otherwise potentially = odd=20 corner cases. > * Fetch this url, generic. > curl does most of what is in http today, store cookies, > follow 301 302 redirections if that feature is enabled, > until it reaches data, or some other condition. > Responses: > - The data, coming over a stream or in a temp file or whatever makes sens= e, > and perhaps the headers as well. > - A request for user name and password, http code 401. > edbrowse-curl shouldn't be doing I/O, edbrowse gets the username > password and sends it back to edbrowse-curl. > - Debugging information if db4, the curl traffic sent and received. > This we just print when we get it and wait for the next response. > - Various urls that the browser is redirected to, if db2. > Again, this is debug information that we just print. > - The new url, the actual location of the page after redirection. > This becomes the "filename" of the page, and the base for relative url re= solution. > - url looks like a streaming mime type. > We usually know this from protocol or suffix, but maybe that wasn't clear > until content-type was compared against your plugins. > - Progress dots, one per megabyte. Again we just print these. No, I think we just download the data, may be have a status message and then it's up to edbrowse what it does. > - Looks like a file you'll want to download, supply a file name or x to a= bort > or space to read in memory as usual. Again, I'd just download the data, if we want to pull it into memory then we can potentially do that, but mean while the data download carries on. I'm thinking that makes more sense because in the case of small files the IO penalty is probably not that high, and in the case of large files we probab= ly don't want to load them into memory anyway. That also gives us a way to implement a sort of page cache in the future if= we=20 want to. > * Fetch this url and download to a file. > This is followup from the previous response, if you requested download to= disk. > We should sent the final url, not the initial url. > Indicate foreground or background. > It's possible that edbrowse-curl doesn't care which, > just a matter of whether edbrowse waits for this to finish or moves on, > but it does matter because edbrowse-curl only sends the progress dots > if download is in the foreground. > Or maybe just an independent parameter for dots or no dots. > They aren't printed when fetching javascript, for instance. See above for thoughts on the dots. At the end of the day, that's aUI decis= ion, i.e. on my internet connection I'd quite like to switch them off entirely tbh because, depending on the server,downloads happen either so fast I can't co= unt the dots or so slowly that having a random dot appearing is not very useful when I don't k= now the actual file size. Try counting how far through a 200 meg download you are in dot form, may be your personal speech adapter does that but on a braille display it's just a huge string of dots and speakup also doesn't do that as far as I kno= w. What I'd actually like is a way to find out the file size (usually from the content-length header) and the actual amount (to the byte preferably) that's actually been downloaded so I can see how long I have to wait. > * cookie name=3Dvalue > This is the result of or by javascript > document.cookie =3D "foo=3Dbar"; > Response:ack - if a response is even required. >=20 > * Get cookies for this url. > These are used to populate document.cookie when javascript starts. That makes sense. Cheers, Adam. --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWhpFgAAoJELZ22lNQBzHOY1oH/0vDoHyu0Ftm8qvdUv6Qo17x uY9OW68x48tcqdR2OQDWfVU2ZgGGzBtl6DaX20iLCO5xPZjE//pqGOwzx6Hj46MV 0aWjdxs7GXOArG/7oIYDZ8ttQpBjiXwOPG6fdIXHCKMkkRJjBiYyeU3xuAhdqM0J iwAb3B4VJz5H09k3fCZMqvNzhePYs0VgY9/jhd+30MGdSqQeaP7aoL58FOZJJVOd hPPj1wx8up/uGvTflBTmMDVCjxIeXZMNWryRexZ+Dx/Uekq6nF0PVAlmNUm34PDI 4kyNMxV7kmsH8ye9Kn9+iUxu91nqDBjyboHhunWa0a/SLd9/BU/8ZRuMLSLQXOQ= =u6f1 -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef--