Yes please. Each executable is a drop-in replacement for the existing proxy executable (but they work slightly differently at login time), so you should run on of them instead of the normal proxy executable. It would be great if you could test both in turn and report whether either of them works.
Cheers,
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With POP3, it was downloading 1 of 5 messages but was stuck at it. The log kept swelling to 25MB and the message didn't get downloading further, whereupon I stopped.
With SMTP, it tried sending 1 message but was stuck at it. The POP3 log (???) kept swelling to 332MB (!), whereupon I stopped.
I tried opening the 332MB file but wordpad froze.
2) Header_RedirFix
Same thing. POP3 log kept swelling. Noticed it kept swelling even after I pressed "Stop" in TB, so I shut down the program.
Bleah.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1)
> With POP3, it was downloading 1 of 5 messages
That implies to me that it managed to authenticate. That's all I need confirmation of. I'm not sure why the log got so large. Was that the .http.log or the .proxy.log?
2)
> Noticed it kept swelling even after I pressed "Stop"
Yeah, as I said before, it continues its work in the background. All Thunderbird does when you press stop is disconnect from the proxy, but by then the proxy is deep in some CPU-bound task...
Try disabling all logging and see you in you have any more luck. Also, don't open 332Mb files in Wordpad... :) Some editors (esp. hex editors) can open files partially (e.g. open the first few megs or whatever). Alternatively, get the GNU head tool (available at http://unxutils.sourceforge.net/ or http://gnuwin32.sourceforge.net/packages/coreutils.htm\). It allows you to output the first N characters of a file on the command line. It would be useful for me to see some of what's going on (or alternatively, if you can characterise what it's doing in words, that would be great too).
A good test would be to disable logging, and crank up the timeout on Thunderbird and just let it get on with it. If it doesn't finish in 5 or 10 minutes, it's probably not going to work.
POP3 access seemed incredibly slow when I tested it, so I'm hoping that's the only problem. Alternatively, the authentication hack may have messed up something a bit later on... If so, I've modified the fix to be slightly more discriminating about when it drops the connection to the server. I'll post a newer version later on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another way of reading the logs is to use the 'more' command, which is included with Windows. It goes through the file a screen at a time, so it doesn't have to load it all in one go. (However, it won't allow you to extract a segment of the data into another file like 'head' would.)
Cheers,
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Try disabling all logging and see you in you have
>any more luck.
Well, I waited for a minute or something and didn't get any mail retrieved. It was stuck at Mail 1 till I stopped.
>A good test would be to disable logging, and
>crank up the timeout on Thunderbird and just let
>it get on with it. If it doesn't finish in 5 or
>10 minutes, it's probably not going to work.
Well 5-10 mins is unacceptable for normal use so you'd need to know what's causing the problem, no?
>POP3 access seemed incredibly slow when I tested
>it, so I'm hoping that's the only problem.
You can't replicate the problem on your side? I wonder why my account's so special, hmm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>Was that the .http.log or the .proxy.log?
>Proxy
That's probably a good sign, in some ways. Again, it suggests that the authentication is working, but that something else is going wrong.
> Well 5-10 mins is unacceptable for normal use so you'd need to know what's causing the problem, no?
Yes, it is unacceptable for normal use. However, don't forget that this is alpha-quality software and the executables I sent you are development versions... If it's any consolation, your efforts are helping get it closer to a reliable piece of software!
> You can't replicate the problem on your side? I wonder why my account's so special, hmm.
No, I have been unable to replicate any of your problems so far. I believe that they are related to the server on which your account resides. It seems to be configured differently than that used for the accounts I have access to. Short of me getting an account with WebDAV access on that (or a similarly configured) server, there's nothing I can do to replicate the problems you are having.
So, I've been relying on your feedback completely. That's why I've been asking you so many questions or asking you to post logs, etc. Without your help, I have absolutely nothing to guide me when investigating the problem...
Don't get me wrong - you're the only person to actually report problems (and I somehow doubt you're the only one having problems), and I appreciate that! However, your problems can only be translated into fixable bugs with enough information and/or a set of steps that I can use to reproduce the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Yes, it is unacceptable for normal use. However,
>don't forget that this is alpha-quality software
Nono. You suggested I disable logging. If I do so you'll never find the problem!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason for disabling logging is that it may be obscuring the real issue. If it doesn't work without logging, we know it doesn't work (but not why). If it doesn't work *with* logging, it may be the logging interfering (especially if it's producing huge files).
So, test it without logging first. If that works, then we can investigate the logs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I don't know much about programming, but a bug involving logging is truly bizarre.
Is it? I believe you meant 'counterintuitive' instead of 'bizarre'.
Logging is often trivial to code, but depending on the way in which the IO is performed, it can modify the overall performance characteristics of the program. It's perfectly possible for a program to become IO bound due to logging (especially due to the way in which logging is performed in Blue, i.e. single byte read/write). I didn't suggest a bug with logging, but instead that it may be obscuring the issue.
In this case, performance is as much an issue as correctness (as you said yourself, when quite rightly saying that 5-10 minutes waiting would be unacceptable). Logging can affect performance, so I suggested that it be turned off. The thing I need to know is whether the operations that the POP proxy undertakes ever actually complete.
I'm sorry that I have to 'remotely debug' through you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's another zip file at http://bhttpmail.sourceforge.net/downloads/HttpMailProxyLoginBug-2006-09-06.zip which contains two executables. These two incorporate the (possible) fix to the login problem. Please give try them and let me know if you have any success.
Cheers,
Rob
I unzip this into the same directory as the normal executables and config XML?
Yes please. Each executable is a drop-in replacement for the existing proxy executable (but they work slightly differently at login time), so you should run on of them instead of the normal proxy executable. It would be great if you could test both in turn and report whether either of them works.
Cheers,
Rob
P.S. If only one of them works, could you tell me its filename?
1) Content_RedirFix.exe
With POP3, it was downloading 1 of 5 messages but was stuck at it. The log kept swelling to 25MB and the message didn't get downloading further, whereupon I stopped.
With SMTP, it tried sending 1 message but was stuck at it. The POP3 log (???) kept swelling to 332MB (!), whereupon I stopped.
I tried opening the 332MB file but wordpad froze.
2) Header_RedirFix
Same thing. POP3 log kept swelling. Noticed it kept swelling even after I pressed "Stop" in TB, so I shut down the program.
Bleah.
1)
> With POP3, it was downloading 1 of 5 messages
That implies to me that it managed to authenticate. That's all I need confirmation of. I'm not sure why the log got so large. Was that the .http.log or the .proxy.log?
2)
> Noticed it kept swelling even after I pressed "Stop"
Yeah, as I said before, it continues its work in the background. All Thunderbird does when you press stop is disconnect from the proxy, but by then the proxy is deep in some CPU-bound task...
Try disabling all logging and see you in you have any more luck. Also, don't open 332Mb files in Wordpad... :) Some editors (esp. hex editors) can open files partially (e.g. open the first few megs or whatever). Alternatively, get the GNU head tool (available at http://unxutils.sourceforge.net/ or http://gnuwin32.sourceforge.net/packages/coreutils.htm\). It allows you to output the first N characters of a file on the command line. It would be useful for me to see some of what's going on (or alternatively, if you can characterise what it's doing in words, that would be great too).
A good test would be to disable logging, and crank up the timeout on Thunderbird and just let it get on with it. If it doesn't finish in 5 or 10 minutes, it's probably not going to work.
POP3 access seemed incredibly slow when I tested it, so I'm hoping that's the only problem. Alternatively, the authentication hack may have messed up something a bit later on... If so, I've modified the fix to be slightly more discriminating about when it drops the connection to the server. I'll post a newer version later on.
Another way of reading the logs is to use the 'more' command, which is included with Windows. It goes through the file a screen at a time, so it doesn't have to load it all in one go. (However, it won't allow you to extract a segment of the data into another file like 'head' would.)
Cheers,
Rob
>Was that the .http.log or the .proxy.log?
Proxy
>Try disabling all logging and see you in you have
>any more luck.
Well, I waited for a minute or something and didn't get any mail retrieved. It was stuck at Mail 1 till I stopped.
>A good test would be to disable logging, and
>crank up the timeout on Thunderbird and just let
>it get on with it. If it doesn't finish in 5 or
>10 minutes, it's probably not going to work.
Well 5-10 mins is unacceptable for normal use so you'd need to know what's causing the problem, no?
>POP3 access seemed incredibly slow when I tested
>it, so I'm hoping that's the only problem.
You can't replicate the problem on your side? I wonder why my account's so special, hmm.
>>Was that the .http.log or the .proxy.log?
>Proxy
That's probably a good sign, in some ways. Again, it suggests that the authentication is working, but that something else is going wrong.
> Well 5-10 mins is unacceptable for normal use so you'd need to know what's causing the problem, no?
Yes, it is unacceptable for normal use. However, don't forget that this is alpha-quality software and the executables I sent you are development versions... If it's any consolation, your efforts are helping get it closer to a reliable piece of software!
> You can't replicate the problem on your side? I wonder why my account's so special, hmm.
No, I have been unable to replicate any of your problems so far. I believe that they are related to the server on which your account resides. It seems to be configured differently than that used for the accounts I have access to. Short of me getting an account with WebDAV access on that (or a similarly configured) server, there's nothing I can do to replicate the problems you are having.
So, I've been relying on your feedback completely. That's why I've been asking you so many questions or asking you to post logs, etc. Without your help, I have absolutely nothing to guide me when investigating the problem...
Don't get me wrong - you're the only person to actually report problems (and I somehow doubt you're the only one having problems), and I appreciate that! However, your problems can only be translated into fixable bugs with enough information and/or a set of steps that I can use to reproduce the problem.
>Yes, it is unacceptable for normal use. However,
>don't forget that this is alpha-quality software
Nono. You suggested I disable logging. If I do so you'll never find the problem!
Oh :)
The reason for disabling logging is that it may be obscuring the real issue. If it doesn't work without logging, we know it doesn't work (but not why). If it doesn't work *with* logging, it may be the logging interfering (especially if it's producing huge files).
So, test it without logging first. If that works, then we can investigate the logs.
>The reason for disabling logging is that it may
>be obscuring the real issue.
I don't know much about programming, but a bug involving logging is truly bizarre.
I'll wait for your slightly modified version anyway.
> I don't know much about programming, but a bug involving logging is truly bizarre.
Is it? I believe you meant 'counterintuitive' instead of 'bizarre'.
Logging is often trivial to code, but depending on the way in which the IO is performed, it can modify the overall performance characteristics of the program. It's perfectly possible for a program to become IO bound due to logging (especially due to the way in which logging is performed in Blue, i.e. single byte read/write). I didn't suggest a bug with logging, but instead that it may be obscuring the issue.
In this case, performance is as much an issue as correctness (as you said yourself, when quite rightly saying that 5-10 minutes waiting would be unacceptable). Logging can affect performance, so I suggested that it be turned off. The thing I need to know is whether the operations that the POP proxy undertakes ever actually complete.
I'm sorry that I have to 'remotely debug' through you!
Right, I'm almost sure this one will work... :)
http://bhttpmail.sourceforge.net/downloads/HttpMailProxyLoginBug-2006-09-07.zip
Let me know how it goes.
Holy Proxies, Batman! It works!!!
It's just about as fast as the Webmail extension too (no noticeable difference in speed).
Excellent!
Thanks again for all your help and testing.
Now it's working, let's see if we can give the Tb Webmail extension a run for its money :)