June 2024 - Dillo-dev - lists.mailman3.com

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Sat, Jun 22, 2024 at 09:43:00AM +1000, Kevin Koster wrote: >But the proxy approach allows old versions/binaries to keep working >too. If Dillo 3.0.5 had supported it, then the HTTPS issues from >lacking SNI support could have been worked around by running an >'old-style' HTTPS proxy with SNI support on localhost. A related term seems to be "reverse proxy": https://en.wikipedia.org/wiki/Reverse_proxy From the "Fun with Crypto Ancienne" post I understand that you want Dillo to get a HTTP or HTTPS URL and always perform a HTTP GET towards your proxy, as the Mosaic configuration suggests: > https 127.0.0.1 8765 http > http 127.0.0.1 8765 http Other that those old browsers, I don't think you can do this with any (relatively) modern tool. This is what Dillo is currently doing for https and http URLs: hop% http_proxy=http://localhost:1234 dillo http://www.google.com hop% nc -l 1234 GET http://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Dillo/3.1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://www.google.com/ Connection: keep-alive hop% http_proxy=http://localhost:1234 dillo https://www.google.com hop% nc -l 1234 CONNECT www.google.com:443 HTTP/1.1 Host: www.google.com:443 While for the latter you'll want: GET https://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Dillo/3.1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate DNT: 1 Referer: https://www.google.com/ Connection: keep-alive You'll need to instruct Dillo to ignore the HTTPS handling and just treat it as an HTTP GET request to the proxy (using the HTTPS url), so no CONNECT is used. >Sure, or actually I'd suggest using a separate variable/option name >to set that proxy server because using "https_proxy" for both proxy >systems is what's already confused me now with Wget. Something >like "https_endpoint=[hostname]" maybe? I think I would have to see it implemented to determine what would be a good name that prevents users from accidentally misconfiguring it. Best, Rodrigo.

June 22, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Thu, Jun 20, 2024 at 04:07:27PM +1000, Kevin Koster wrote: >>My content-modifying proxy application might be very niche, but I still >>think it would be more widely useful for people running Dillo on very >>old computers. Let me know whether it's something that might be accepted >>for Dillo even if I decide to try implementing it myself. > > Provided that those machines cannot deal with HTTPS traffic, I think is > a reasonable use case. I haven't had time to dig a bit more into this > issue to see if there is a way to make those old machines use TLS > instead Oh there is, the Crypto Ancienne TLS library is designed for this: https://github.com/classilla/cryanc I started work on supporting it for HTTPS in Dillo, and got far enough that I'm sure the library would work for it, though I didn't finish debugging my attempt. That was while Dillo 3.1 looked abandoned so I did it as a HTTPS DPI plug-in, which makes my work obsolete now. But the proxy approach allows old versions/binaries to keep working too. If Dillo 3.0.5 had supported it, then the HTTPS issues from lacking SNI support could have been worked around by running an 'old-style' HTTPS proxy with SNI support on localhost. > I won't oppose to it, but we probably want to ensure that we don't send > plain traffic to a proxy when browsing HTTPS pages by accident. We > should add an option like "allow_insecure_proxy" (false by default) or > similar, so it is harder to leak HTTPS traffic accidentally. Sure, or actually I'd suggest using a separate variable/option name to set that proxy server because using "https_proxy" for both proxy systems is what's already confused me now with Wget. Something like "https_endpoint=[hostname]" maybe?

June 21, 2024

Re: problem with compressed or encrypted url

by Rodrigo Arias

Hi, On Fri, Jun 21, 2024 at 09:52:06AM +1000, Kevin Koster wrote: >pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: >> Hi >> >> someone please tell me what is wrong when i do >> >> dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… >> >> it seems to be encrypted or compressed? > >It failed the first time for me, then trying a little later it >loads. In between I tried using "wget -S --spider" and the first >time the header showed it was compressed using Brotli compression: >"content-encoding: br" > >On subsequent tries it returned uncompressed data to Wget and >Dillo, which is correct since neither supports Brotli compression. >It appears that the originating Web server is mis-configured to >use Brotli compression even if the client doesn't announce support >for it. >[...] >The difference appears to be whether the page is served from a >cache server. The cache server still latter notices the browser's >Accept-Encoding header and doesn't use Brotli compression. Very good analysis, thanks :-) I reported the issue upstream: https://github.com/canonical/ubuntu.com/issues/13980 Best, Rodrigo.

June 21, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi Kevin, On Thu, Jun 20, 2024 at 04:07:27PM +1000, Kevin Koster wrote: >On Thu, 20 Jun 2024 10:03:59 +1000 >"Kevin Koster" <dillo(a)ombertech.com> wrote: > >> Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> >> wrote: >> > However, if you start Dillo from a shell where the http_proxy >> > variable is set in the environment, I would imagine it would be >> > already picked by Dillo and the internal wget command. The dpid >> > daemon has to start from this shell, so you should do a "dpidc stop" >> > command before to ensure it. >> >> I'm not sure if we're on the same page, Wget supports http_proxy >> and https_proxy environment variables. The former may or may not >> tunnel HTTPS requests through a Web proxy, but that's not what I >> want since then the proxy can't manipulate the data and the client >> needs to handle the encryption. https_proxy with Wget uses the >> proxy to do all the encryption and therefore those issues don't >> apply. More browsers support the HTTPS tunneling proxy feature, >> but that doesn't achieve anything that I'm interested in >> personally. > >I did some tests and yes the https_proxy environment variable is picked >up by Wget for the downloads DPI. It doesn't affect Dillo itself. The >http_proxy environment variable is picked up by Dillo, but as I say that >doesn't do what I want with Dillo or Wget. > >It appears that GNU Wget's behaviour has changed. Newer versions _do_ >try to tunnel the HTTPS connection through the proxy set to https_proxy >(not what I want), whereas older versions ask that proxy to establish >the HTTPS connection and send data back unencrypted (which is what I >want). So I picked a bad example with Wget. See that blog post for other >examples like Lynx, but I haven't tried them myself. > >I can't find this change in the Wget changelog. One version that works >as I intend it to is GNU Wget 1.9, circa 2003. Looking through the Wget >mailing list archives it seems like many people either considered the >old behaviour a bug or a useless feature, so I may be swimming against >the tide. > >My content-modifying proxy application might be very niche, but I still >think it would be more widely useful for people running Dillo on very >old computers. Let me know whether it's something that might be accepted >for Dillo even if I decide to try implementing it myself. > >Sorry for the confusion. Provided that those machines cannot deal with HTTPS traffic, I think is a reasonable use case. I haven't had time to dig a bit more into this issue to see if there is a way to make those old machines use TLS instead, which I think it would be preferred. I won't oppose to it, but we probably want to ensure that we don't send plain traffic to a proxy when browsing HTTPS pages by accident. We should add an option like "allow_insecure_proxy" (false by default) or similar, so it is harder to leak HTTPS traffic accidentally. In any case, support for https_proxy should be added to Dillo first. Best, Rodrigo.

June 21, 2024

Re: problem with compressed or encrypted url

by pastebin＠gmx.com

Hi Kevin, Thanks - for spending the time figuring this out - it is interesting what you did - i never would have imagined it was 'brotli and a misconfigured server' it never came through uncompressed here - even after a few attempts - i wonder what someone looking at the logs thougth about - so many multiple loadings of a url about secureing sshd lol brotli appears to be a google invention - i wonder about how it got into a misconfigured server :) if it ever comes up for a vote - i vote no to include brotli into dillo ;) On Fri, 21 Jun 2024 09:52:06 +1000 "Kevin Koster" <dillo(a)ombertech.com> wrote: > pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: > > Hi > > > > someone please tell me what is wrong when i do > > > > dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… > > > > it seems to be encrypted or compressed? > > It failed the first time for me, then trying a little later it > loads. In between I tried using "wget -S --spider" and the first > time the header showed it was compressed using Brotli compression: > "content-encoding: br" > > On subsequent tries it returned uncompressed data to Wget and > Dillo, which is correct since neither supports Brotli compression. > It appears that the originating Web server is mis-configured to > use Brotli compression even if the client doesn't announce support > for it. > > I found another page on the Ubuntu site where the problem still > happens for me: > > ---- > $ wget --spider -S https://ubuntu.com/navigation > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:41:41-- https://ubuntu.com/navigation > Resolving ubuntu.com... 185.125.190.20, 185.125.190.29, 185.125.190.21, ... > Connecting to ubuntu.com|185.125.190.20|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 > server: nginx/1.14.0 (Ubuntu) > date: Thu, 20 Jun 2024 23:41:14 GMT > content-type: text/html; charset=utf-8 > x-view-name: webapp.views.navigation_nojs > x-clacks-overhead: GNU Terry Pratchett > permissions-policy: interest-cohort=() > cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 > x-frame-options: SAMEORIGIN > x-content-type-options: NOSNIFF > x-vcs-revision: 1718884808-1dd74d9 > x-request-id: c211f00fd2212b0b8771952d7fa04558 > strict-transport-security: max-age=15724800 > link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect > content-encoding: br > x-cache-status: STALE from content-cache-il3/0 > Length: unspecified [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > > After retrying a few times I got an unencrypted response: > > ---- > $ wget --spider -S https://ubuntu.com/navigation > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:46:12-- https://ubuntu.com/navigation > Resolving ubuntu.com... 185.125.190.21, 185.125.190.29, 185.125.190.20, ... > Connecting to ubuntu.com|185.125.190.21|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 > server: nginx/1.14.0 (Ubuntu) > date: Thu, 20 Jun 2024 23:45:45 GMT > content-type: text/html; charset=utf-8 > content-length: 202990 > x-view-name: webapp.views.navigation_nojs > x-clacks-overhead: GNU Terry Pratchett > permissions-policy: interest-cohort=() > cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 > x-frame-options: SAMEORIGIN > x-content-type-options: NOSNIFF > x-vcs-revision: 1718884808-1dd74d9 > x-request-id: 67baf729cf4344e46b689b28c5efb56f > strict-transport-security: max-age=15724800 > link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect > x-cache-status: HIT from content-cache-il3/1 > accept-ranges: bytes > Length: 202990 (198K) [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > > The difference appears to be whether the page is served from a > cache server. The cache server still latter notices the browser's > Accept-Encoding header and doesn't use Brotli compression. > > While checking docs for the headers, I found this page has the same > problem (again in both Dillo and Wget): > > ---- > $ wget -S --spider --compression=gzip https://http.dev/compression > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:30:10-- https://http.dev/compression > Resolving http.dev... 34.120.39.70 > Connecting to http.dev|34.120.39.70|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > content-type: text/html; charset=utf-8 > strict-transport-security: max-age=63072000; includeSubDomains; preload > pragma: public > cache-control: public, max-age=86400 > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > x-ua-compatible: IE=Edge,chrome=1 > x-xss-protection: 1; mode=block > vary: Accept-Encoding > x-versionid: 8Bp0x4p9 > x-production: True > link: <https://http.dev/css/app.min.css?v=8Bp0x4p9>; rel="preload"; as="style" > x-request-id: fc33d19c-441a-4fab-ae1b-113e5e9028f5 > content-encoding: br > x-cloud-trace-context: a7d7fda8062ff6c0a9a86187afcacecb;o=1 > Content-Length: 8989 > date: Thu, 20 Jun 2024 23:29:42 GMT > server: Google Frontend > via: 1.1 google, 1.1 google > Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 > Length: 8989 (8.8K) [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 21, 2024

Re: problem with compressed or encrypted url

by Kevin Koster

pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: > Hi > > someone please tell me what is wrong when i do > > dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… > > it seems to be encrypted or compressed? It failed the first time for me, then trying a little later it loads. In between I tried using "wget -S --spider" and the first time the header showed it was compressed using Brotli compression: "content-encoding: br" On subsequent tries it returned uncompressed data to Wget and Dillo, which is correct since neither supports Brotli compression. It appears that the originating Web server is mis-configured to use Brotli compression even if the client doesn't announce support for it. I found another page on the Ubuntu site where the problem still happens for me: ---- $ wget --spider -S https://ubuntu.com/navigation Spider mode enabled. Check if remote file exists. --2024-06-21 09:41:41-- https://ubuntu.com/navigation Resolving ubuntu.com... 185.125.190.20, 185.125.190.29, 185.125.190.21, ... Connecting to ubuntu.com|185.125.190.20|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 server: nginx/1.14.0 (Ubuntu) date: Thu, 20 Jun 2024 23:41:14 GMT content-type: text/html; charset=utf-8 x-view-name: webapp.views.navigation_nojs x-clacks-overhead: GNU Terry Pratchett permissions-policy: interest-cohort=() cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 x-frame-options: SAMEORIGIN x-content-type-options: NOSNIFF x-vcs-revision: 1718884808-1dd74d9 x-request-id: c211f00fd2212b0b8771952d7fa04558 strict-transport-security: max-age=15724800 link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect content-encoding: br x-cache-status: STALE from content-cache-il3/0 Length: unspecified [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ---- After retrying a few times I got an unencrypted response: ---- $ wget --spider -S https://ubuntu.com/navigation Spider mode enabled. Check if remote file exists. --2024-06-21 09:46:12-- https://ubuntu.com/navigation Resolving ubuntu.com... 185.125.190.21, 185.125.190.29, 185.125.190.20, ... Connecting to ubuntu.com|185.125.190.21|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 server: nginx/1.14.0 (Ubuntu) date: Thu, 20 Jun 2024 23:45:45 GMT content-type: text/html; charset=utf-8 content-length: 202990 x-view-name: webapp.views.navigation_nojs x-clacks-overhead: GNU Terry Pratchett permissions-policy: interest-cohort=() cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 x-frame-options: SAMEORIGIN x-content-type-options: NOSNIFF x-vcs-revision: 1718884808-1dd74d9 x-request-id: 67baf729cf4344e46b689b28c5efb56f strict-transport-security: max-age=15724800 link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect x-cache-status: HIT from content-cache-il3/1 accept-ranges: bytes Length: 202990 (198K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ---- The difference appears to be whether the page is served from a cache server. The cache server still latter notices the browser's Accept-Encoding header and doesn't use Brotli compression. While checking docs for the headers, I found this page has the same problem (again in both Dillo and Wget): ---- $ wget -S --spider --compression=gzip https://http.dev/compression Spider mode enabled. Check if remote file exists. --2024-06-21 09:30:10-- https://http.dev/compression Resolving http.dev... 34.120.39.70 Connecting to http.dev|34.120.39.70|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK content-type: text/html; charset=utf-8 strict-transport-security: max-age=63072000; includeSubDomains; preload pragma: public cache-control: public, max-age=86400 x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-ua-compatible: IE=Edge,chrome=1 x-xss-protection: 1; mode=block vary: Accept-Encoding x-versionid: 8Bp0x4p9 x-production: True link: <https://http.dev/css/app.min.css?v=8Bp0x4p9>; rel="preload"; as="style" x-request-id: fc33d19c-441a-4fab-ae1b-113e5e9028f5 content-encoding: br x-cloud-trace-context: a7d7fda8062ff6c0a9a86187afcacecb;o=1 Content-Length: 8989 date: Thu, 20 Jun 2024 23:29:42 GMT server: Google Frontend via: 1.1 google, 1.1 google Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 Length: 8989 (8.8K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ----

June 20, 2024

problem with compressed or encrypted url

by pastebin＠gmx.com

Hi someone please tell me what is wrong when i do dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… it seems to be encrypted or compressed? i can get it with curl okay and then dillo on the resulting html is good

June 20, 2024

Re: HTTPS Proxy Support

by Kevin Koster

On Thu, 20 Jun 2024 10:03:59 +1000 "Kevin Koster" <dillo(a)ombertech.com> wrote: > Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> > wrote: > > However, if you start Dillo from a shell where the http_proxy > > variable is set in the environment, I would imagine it would be > > already picked by Dillo and the internal wget command. The dpid > > daemon has to start from this shell, so you should do a "dpidc stop" > > command before to ensure it. > > I'm not sure if we're on the same page, Wget supports http_proxy > and https_proxy environment variables. The former may or may not > tunnel HTTPS requests through a Web proxy, but that's not what I > want since then the proxy can't manipulate the data and the client > needs to handle the encryption. https_proxy with Wget uses the > proxy to do all the encryption and therefore those issues don't > apply. More browsers support the HTTPS tunneling proxy feature, > but that doesn't achieve anything that I'm interested in > personally. I did some tests and yes the https_proxy environment variable is picked up by Wget for the downloads DPI. It doesn't affect Dillo itself. The http_proxy environment variable is picked up by Dillo, but as I say that doesn't do what I want with Dillo or Wget. It appears that GNU Wget's behaviour has changed. Newer versions _do_ try to tunnel the HTTPS connection through the proxy set to https_proxy (not what I want), whereas older versions ask that proxy to establish the HTTPS connection and send data back unencrypted (which is what I want). So I picked a bad example with Wget. See that blog post for other examples like Lynx, but I haven't tried them myself. I can't find this change in the Wget changelog. One version that works as I intend it to is GNU Wget 1.9, circa 2003. Looking through the Wget mailing list archives it seems like many people either considered the old behaviour a bug or a useless feature, so I may be swimming against the tide. My content-modifying proxy application might be very niche, but I still think it would be more widely useful for people running Dillo on very old computers. Let me know whether it's something that might be accepted for Dillo even if I decide to try implementing it myself. Sorry for the confusion.

June 20, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Wed, Jun 19, 2024 at 01:15:52PM +1000, Kevin Koster wrote: >>As mentioned in the discussion about link handlers and webpage >>content rewriting, I once looked into using Web proxy software to >>do the latter. One complication was that Dillo doesn't support >>a feature equivalent to setting the https_proxy environment >>variable for GNU Wget, whereby the proxy acts as the HTTPS >>endpoint for encrypted Web server connections and sends the data >>back to the browser unencrypted. This allows the proxy to >>manipulate page content without needing to transform HTTP requests >>into HTTPS requests and rewrite https:// in page URLs as http://. > > This should be easy to do, as Dillo can forward the http_proxy variable > to the wget command. > > However, if you start Dillo from a shell where the http_proxy variable > is set in the environment, I would imagine it would be already picked by > Dillo and the internal wget command. The dpid daemon has to start from > this shell, so you should do a "dpidc stop" command before to ensure it. I'm not sure if we're on the same page, Wget supports http_proxy and https_proxy environment variables. The former may or may not tunnel HTTPS requests through a Web proxy, but that's not what I want since then the proxy can't manipulate the data and the client needs to handle the encryption. https_proxy with Wget uses the proxy to do all the encryption and therefore those issues don't apply. More browsers support the HTTPS tunneling proxy feature, but that doesn't achieve anything that I'm interested in personally. Anyway Wget https_proxy is only a common example of the feature (which is described in more detail at the blog link), I'm not so much interested in using it when Dillo launches Wget for downloads, but for data retrieved by Dillo itself to display within the browser. >>Besides proxies, for old computers where performance or available >>TLS library versions prevent using modern encryption, this also >>allows the encrypted communications to be offloaded to more modern >>computer. Or using a different encryption library that's optimised >>for old computers, as described here: >> >>http://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html >> >>For using this with old computers, it would be ideal if the HTTPS >>proxy feature was available even if Dillo is compiled without >>linking to a TLS library. Also the https_proxy environment variable >>should be set to the HTTPS proxy hostname when running Wget for >>downloads so that it applies to those as well. > > Sounds doable, but I would have to review how the HTTPS traffic is > handled in Dillo when a proxy is present. I did look into this with Dillo 3.0.5 and I'm confident this HTTPS proxy feature wasn't supported already there, but I never worked out exactly where the feature would fit into that code (which is likely quite different now anyway since moving out of the DPI environment).

June 20, 2024

Re: Option to define external link handler

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Wed, Jun 19, 2024 at 10:03:20AM +1000, Kevin Koster wrote: >>This mechanism might suit an idea I've had to do remote downscaling >>of extremely large images, which are increasingly being included in >>web pages. The script would send a list of URLs in all <img> tags >>within the HTML to a remote server (eg. on a VPS), or ideally just >>the ones for large image files, then rewrite the URLs in the HTML >>to point to the remote server where the converted images are >>available over HTTP/S. > > You can create a script that rewrites the <img> src attribute > > <img src="https://foo.com/img1.png"> > > To point to an endpoint of your server: > > <img src="https://yourserver.com/downscale?url=https://foo.com/img1.png"> Yes that would work too, however the idea of sending a URL list was that it allows my server to re-use the HTTPS connection to the image host server while downloading lots of images for a webpage, whereas the way you have it each image request by my server would be a new HTTPS connection, and therefore potentially slower. It's a minor difference though. > And then in the server you simply downscale it. Here is how you could do > it with rules: > > # Script that would rewrite images to a server for downscaling > action downscale filter 'rewrite-img.sh' > define mime header 'Content-Type' > match mime 'text/html' action downscale That should work. I would personally find it clearer to read if there was a character indicating assignment values, since this would make it obvious which words are commands and which are arguments. Such as: # Script that would rewrite images to a server for downscaling action downscale filter='rewrite-img.sh' define mime header='Content-Type' match mime='text/html' action=downscale Using "action" as an argument to "match" as well as the name of a command might still be a little confusing. >>Or a deeper approach would be to apply the same approach as this >>rewrite engine to binary content as well, and have Dillo do it >>transparently via 'rewrite'/convert rules for image MIME types. >>Then the HTML would stay the same and Dillo would trigger a command >>that requested a downscaled image from the converter server instead >>of the original image's server. That would be more elegant, but >>expands the scope of your proposed system a little. > > Rewriting the binary image directly would be possible, but then you > would have wasted the bandwidth bringing it to Dillo, and now you have > to send it to the server to downscale it. No the idea is to reduce the bandwidth usage on Dillo's connection, so for this approach Dillo would have to abort the connection to the image server if the image size was over the limit and fetch it from the script instead, which might do: wget -q -O - "https://yourserver.com/downscale?url=https://foo.com/img1.png" A way to get Dillo to take the replacement URL from the script would be better, but I suspect that would make this system more complicated to implement because then state matters between different connections. Granted I've lost the ability to re-use the HTTPS connection at my server with this approach. I like how it wouldn't affect the performance of fetching small images by waiting for them to be needlessly downloaded by my server first though, which would generally be a bigger advantage overall. Most images are still small enough that I wouldn't down-scale them, just the 1MB+ ones would get that treatment. The surprise 10MB+ ones are the real evil, and just the option to block these outright (abort the connection and don't run any script) would be better than nothing. To complicate things further, it would be good to have a right-click menu option to bypass this rule and allow fetching the full-size image. Alternatively an external handler could be assigned (via the earlier-discussed mechanism) to a script that downloads and opens the image URL in an external image viewer, which might actually be better to use for that. > In any case, imagine you want to downscale it locally anyway. Here is > how I can think about it: > > # Script that would downscale an image and write to stdout > action downscale filter 'downscale-img.sh' > > # Define headers from the HTTP content with shorter names > define mime header 'Content-Type' > define size header 'Content-Length' > > # Downscale big images > match mime =~ 'image/.*' and size > 10K action downscale > > Notice that this can be triggered for any image, not only ones provided > via HTTP/HTTPS, but also via other protocols like gemini that are > adapted to speak HTTP and also provide a Content-Length header. > > I added the =~ and > operators, as the former would match a regex and the > latter will use a numeric comparator. You can assume that the default if > the header is not present is to make any comparison fail. > > I have also added the "define" keyword to define properties like "mime" or > "size" which are parsed from the HTTP headers and are shorter and easier > to write. That looks good. Maybe I'd find it clearer without the whitespace between operators as with my '=' example above. >>Maybe since it still requires a remote Web server this problem >>would be better solved via a Web proxy (I did look into Squid >>before, but drowned in confusing documentation). But I just thought >>I'd mention it as an example of a more complex usage for this >>proposed rewrite system. > > But then you will need to pass all the traffic through the server so it > performs the substitution there. > > Another solution which may be better is to mark from Dillo which > requests are being done from img elements (filtering them before going > to the network). > > If Dillo marks those requests in the HTTP headers for example, then you > could do: > > # Script that transforms image HTTP requests to a server that > # downscales the image > action downscale filter 'downscale-req.sh' > > define source header 'Dillo-Request-Source' > > # Downscale images comming from <img> elements > match source 'img' action downscale Yes, that's neat. > This would have the benefit that Dillo already performs the parsing of > the HTML for you, and only the images that are loaded are passed to the > downscaling server. Additionally, cookies would be sent in the HTTP > request, so you can access login protected images this way too. Good point, although for my usage login protected images wouldn't be much of a concern.

June 19, 2024