The thing we have to remember, I have to remember, is when the second page issues a 403 error, there's no point in looking at the second page, neither its html nor its js nor its css.
The error occurred before we got any of that data.
It's all about the first page, and the http exchange to fetch the second page, which looks right to me, according to db4.
I did something I haven't done in years, downloaded lynx and ran it.
With no screen readers etc, this is the only other browser I can run.
I pulled up the home page, put in a fake login and password, went to the next page, and got the same 403.
So lynx doesn't handle it either, and lynx probably does cookies properly, and certainly sends the post request properly, so that rules out a couple of things.

The next step, which I am not able to do, is to run this in chrome or firefox and sniff the packets as they go by,
and see exactly what http headers it is sending to gkg to get the second page.
If you have a proxy server with monitor perhaps you could use that instead of a packet sniffer.
That might be worthwhile if we were serious about debugging edbrowse in the ongoing future,
so we could compare and contrast internet traffic.
Logically, if we send exactly the same http headers as firefox, it will work.
Yes, I tried changing the user agent, that didn't help.

By coincidence, tsp ran into a 403 error, and we fixed it by fixing referer, which is part of the http headers, and was not being sent properly.
I was hoping that was it here, but referer looks right.

Karl Dahlke