Dear list, is the https plugin supposed to work? Whenever I select a https URL dpid gets started but nothing happens whatsoever. I do have SSL enabled and all. I am aware that there is some work needed and that https support is considered as very basic. But what is supposed to be working atm? It is easier to fix bugs if you know what it should look like... Thanks, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Fri, Mar 14, 2008 at 07:19:45PM +0100, Christian Kellermann wrote:
Dear list,
is the https plugin supposed to work?
My take on the status of https is that it's currently my biggest itch! :-) I've been gdb-ing dillo-fltk (looking at it from the other end from you, as it were), and I can see the CCC setting up tearing down the IO links, so it looks as though the dillo process is talking to something, and getting something sensible from it. But AFAICT the https filter dpi isn't even starting (it should dump some startup messages to stdout which I'm not seeing). Like you I'd appreciate some guidance from those wiser than myself. Getting https working would greatly reduce the number of times I run Firefox! Regards, Jeremy Henty
On Fri, Mar 14, 2008 at 11:35:38PM +0000, Jeremy Henty (ie. me) wrote:
... I can see the CCC setting up tearing down the IO links, so it looks as though the dillo process is talking to something, and getting something sensible from it. But AFAICT the https filter dpi isn't even starting (it should dump some startup messages to stdout which I'm not seeing).
I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong. Jeremy Henty
On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote:
I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong.
And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see: [https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} which at least gives some idea of what is going wrong. Jeremy Henty
Jeremy wrote:
On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote:
I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong.
And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see:
[https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi}
which at least gives some idea of what is going wrong.
It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...
On Sat, Mar 15, 2008 at 02:18:27AM +0000, place wrote:
It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...
Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix? I'm just guessing here, I'm still figuring out this code. Regards, Jeremy Henty
* Jeremy Henty <onepoint@starurchin.org> [080315 05:58]:
On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote:
I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong.
And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see:
[https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi}
If you add an additional MSG output you see something like this: [https dpi]: {In https.filter.dpi} [https dpi]: dpip_tag <cmd='open_url' url='https://www.ccc.de' '> [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} dpid_tag looks like there is a missing '. I added Index: dpi/https.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/dpi/https.c,v retrieving revision 1.1.1.1 diff -b -u -p -r1.1.1.1 https.c --- dpi/https.c 6 Oct 2007 22:36:34 -0000 1.1.1.1 +++ dpi/https.c 15 Mar 2008 07:51:29 -0000 @@ -191,6 +191,9 @@ static void yes_ssl_support(void) /*Get the network address and command to be used*/ dpip_tag = sock_handler_read(sh); + + MSG("dpip_tag %s\n",dpip_tag); + cmd = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cmd"); url = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "url"); http_query = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "query"); I am not sure whether this is really save, is this tag \0 terminated? Nonetheless something is lost on the way... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
Hi, nevermind the last post the dpid_tag _is_ syntactically correct. Why should http_query be missing though? Shouldn't it at least be the same as url? Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
Hi, Just a follow up on https dpi:
[place wrote] It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...
Yes this is a bug from the latest big dpi upgrade (generic dpi protos).
[Jeremey wrote] Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix?
"proto.https" is the right patch.
[Christian wrote] But what is supposed to be working atm?
Really basic, if you can see: https://www.rapidssl.com/test/rapidssl.htm that's all. BTW, with place's patch, I can also see: https://www.ccc.de
[Jeremey wrote] Getting https working would greatly reduce the number of times I run Firefox!
I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-)
[...]
With regard to the missing dialog function, you may get a very good idea by looking at its implementation in dillo-0.8.6. That's what I'd do to answer if I had the time now. -- Cheers Jorge.-
On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote:
[Jeremey wrote] Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix?
"proto.https" is the right patch.
OK, what about my patch to redirect MSG debugging messages from stdout to stderr? Is that correct? Regards, Jeremy Henty
On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote:
On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote:
[Jeremey wrote] Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix?
"proto.https" is the right patch.
OK, what about my patch to redirect MSG debugging messages from stdout to stderr? Is that correct?
Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now. -- Cheers Jorge.-
On Thu, Mar 20, 2008 at 09:37:13AM -0400, Jorge Arellano Cid wrote:
On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote:
OK, what about my patch to redirect MSG debugging messages from stdout to stderr? Is that correct?
Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now.
OK, I see. I wasn't expecting anything to *write* to the stdin descriptor so I assumed something was wrong. Regards, Jeremy Henty
On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote:
[Jeremey wrote] Getting https working would greatly reduce the number of times I run Firefox!
I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-)
Well, I can surf my ISPs forums with dillo-fltk now that https is working. That's something! Regards, Jeremy Henty
participants (4)
-
Christian.Kellermann＠nefkom.net -
jcid＠dillo.org -
onepoint＠starurchin.org -
place＠gobigwest.com