01:43 <freemint> I found out why css was not working, and i have a problem with http.l now

01:45 <freemint> The problem is that it generates links like http://xn--schg-noa:80.de/my.css for style-sheets and http://xn--schg-noa.de/ as base ref

03:32 <freemint> should uee https instead without any port hints

08:50 <freemint> Good Morning

08:51 <Regenaxer> Hi freemint

08:51 <freemint> Firefox complains about mixed content (a ssl website loading non ssl content which is why css does not work)

08:52 <Regenaxer> httpGate

08:52 <freemint> Before that it did not work because i told nginx accidentally that it can fetch images, css and js from a local folder, which it could no

08:53 <freemint> unless http_gate rewrites the html it would not fix the problem

08:54 <freemint> the problem is that the html says http://xn--schg-noa:80.de/my.css when it should https://xn--schg-noa.de/my.css

08:55 <Regenaxer> No, you dont need ":80" with httpGate

08:55 <Regenaxer> Anyway, I can't comment on Nginx usage

08:56 <freemint> nginx works i just talked about failure mode i had which exposed my current failure.

08:57 <Regenaxer> No idea, sorry

08:57 <freemint> My problem is that i am using http.l in a way that produces the "wrong link"

08:57 <Regenaxer> I would use httpGate, perhaps some other port if 80 or 443 is not free

08:58 <Regenaxer> There are no wrong links if you use pil/httpGate properly

08:58 <Regenaxer> It generates and translates all links and ports

09:00 <freemint> httpGate parses the complete html and rewrites all the ports?

09:00 <freemint> *links

09:01 <freemint> httpGate parses the complete outgoing html reply and rewrites all the links?

09:01 <freemint> Is that what you are saying?

09:03 <Regenaxer> No, the pil server communicates with httpGate

09:04 <Regenaxer> Read doc/httpGate.html

09:07 <freemint> the problem is that the html says http://xn--schg-noa:80.de/my.css when it should https://xn--schg-noa.de/my.css. Both urls provide the same content but due to a firefox policy on "mixed content" i can not have a http:// link to a stylesheet in a website that was delivered via https://

09:14 <Regenaxer> Just point it to httpGate

09:14 <Regenaxer> Then use httpGate to start your pil servers

09:14 <Regenaxer> or start them yourself and give httpGate a local port

09:15 <Regenaxer> The normas setup is that httpGate listens on port 443

09:15 <freemint> hte encryption has to be handled by nginx using httpgate is impossible, since i have other services not running on picolisp.

09:15 <Regenaxer> Sorry, not my problem

09:17 <Regenaxer> afp

09:46 <freemint> Why do '^ and (baseHRef) have almost the same code?

09:50 <freemint> and why is ^ never called?

10:02 <freemint> Forget the comments about ^ for some reason ^ appeared in (who '*Gate)

10:10 <freemint> Solved my problem: the most helpfull answer would have been. http.l and xhtml.l are only expected to handle ssl if they are talking with HTTPgate. You can emulate that by setting '*Gate to "https" in the main.l and redefine baseHRef (which is the the place involved with generating all urls) so that you come into problem with the *Gate style domain.tld/port/request

10:17 <freemint> *Gate is set indirectly by httpGate (i assume by looking at the forwarded http request)

10:18 <freemint> and the header/cookies

10:52 <freemint> Regenaxer, let me compliment, your software is supremely debuggable if you have a hunch how it works and of it's principles

14:56 <Regenaxer> ret

14:58 <Regenaxer> In fact http and xhtml don't handle ssl at all, they are not aware of it except for a single case, the *Gate variable

14:59 <Regenaxer> So it seems you found the right place

15:01 <Regenaxer> But I still believe the best would be to start httpGate, perhaps on another port and connect that from nginx (though, as I said, I have no clear idea of what nginx does)

15:01 <Regenaxer> httpGate always appears as a server on a single port to whoever connects to it

15:55 <freemint> Regenaxer, can i force httpGate to tell via *Gate that it is using https even when i access it over port 443 only?

16:15 <Regenaxer> Hm, this is the normal case, no?

16:15 <Regenaxer> httpGate does not care of the port number

16:16 <Regenaxer> If a cert is passed, it uses ssl

16:16 <Regenaxer> otherwise no encryption, no matter which ports is given to listen at

16:18 <Regenaxer> Can't you start eg. bin/httpGate 1443 names pem.key,pem.crt ?

16:18 <Regenaxer> then forward from nginx to 1443 somehow

16:20 <Regenaxer> Or ignore nginx completely, open 1443 in the firewall, and use https://myserver:1443/app

16:21 <Regenaxer> I have that on a customer's machine. 3 httpGates, listening on 80 (for letsecrypt only), 443 (normal usag) and 2xxxxx (for a separate setup)

16:38 <freemint> mhh looks like the easiest solution is to have a self signed certificate to feed httpGate and let nginx handle the let's encrypt certificate.

16:38 <freemint> (with my setup of virtual hosts who run non picolisp software depending on path filterting for security.

16:39 <Regenaxer> Hmm, cert is an issue, yes. Self-signed is not so nice indeed

16:41 <freemint> nginx does not check certs when it is proxying hosts on local network.

16:41 <Regenaxer> Seems like you need a separate domain for Let's encrypt? I never thought about it

16:41 <freemint> You need a publicly accessable domain

16:41 <Regenaxer> yes, thought so

16:42 <freemint> I could construct a vodoo setup with reusing a cert i created publically for local network but that makes everything even more complicated

16:42 <Regenaxer> I also used some self-signed certs years ago, but that was no longer needed

16:43 <freemint> the self signed would only be visible internally nginx would make everything look let's encrypt on the outside.

16:44 <Regenaxer> So your solution of setting '*Gate to "https" is OK

16:44 <Regenaxer> I did not think baseHRef needs to be redefined

16:45 <freemint> It needs because *Gate implies => domain.tld/Port/query

16:45 <Regenaxer> yes, but thats needed

16:45 <Regenaxer> Port is handled by httpGate

16:45 <freemint> nut it even does that for port 80

16:46 <freemint> picolisp server gets schäg.de/80/!aboutme

16:46 <Regenaxer> But I *do* use it this way

16:46 <freemint> and complains that accessing 80/ is not in allowed

16:47 <Regenaxer> 80 is never involved

16:47 <Regenaxer> I use 2xxxxx

16:48 <Regenaxer> bin/httpGate 2xxxxx names certs

16:48 <freemint> mhh i look into it but self signed is the easier solution

16:48 <Regenaxer> users connect to https://host:2xxxx/foobar

16:49 <Regenaxer> neither 80 nor 443 is involved

16:49 <Regenaxer> yes, if you cannot read-acces the nginx cert

16:49 <Regenaxer> but perhaps you can?

16:50 <freemint> I can't proper isolation, also cert would be for the wrong domain not the internal 10.0.2.2 but for schäg.de

16:51 <Regenaxer> I thought you *want* to access from outside

16:51 <Regenaxer> -> schäg.de

16:51 <Regenaxer> For internal access self-signed is ok

16:53 <Regenaxer> So this one really does not work? bin/httpGate 2443 names /path/to/letsencrypt/certs

16:56 <freemint> Regenaxer, i try later but the picolisp vm is 10.0.2.2 and not schäg.de

16:56 <Regenaxer> ok

16:57 <Regenaxer> then self-signed. LetsEncrypt does not work with IP-addresses

16:58 <freemint> I am sorry i took so long for to explain the circumstances properly

16:59 <Regenaxer> no problem

16:59 <Regenaxer> what I told above was also wrong

16:59 <Regenaxer> The customer setup on a third port works only in LAN

16:59 <Regenaxer> I just tried. I runs since many years and I forgot the details

17:00 <freemint> the reason why i do not go with the port option is schäg.de is because schäg.de is supposed to be my homepage and a schäg:88.de would be weird.

17:30 <freemint> anyway Regenaxer debugging the "wrong" urls was a bliss in picolisp. i never realized the potential of ! until i ran it with the webserver running and could inspect anything

17:31 <Regenaxer> Thanks, glad to hear :)

17:31 <freemint> it was quiet fun to "write" html code for a running session