Thanks Tom.

 

I can confirm that if I access the GUI from IE, it does work, it's only an issue for me in Firefox.  Now that I know I can just clear the cookies for my IP address and reaccess the GUI, it's not such a big deal.  I'll wait, and look forward to your fix in the next beta.

 

thanks again!

I suspect what's happening is that the Deluge webui is sending a very long cookie to the browser.  Later when you request a normal page from the unRaid webGui, the browser is sending the same cookie in the header lines included with the GET request.  This is because the browser doesn't know which UI it's talking to - the unRaid webGui is on the same IP address as the Deluge webui (port is not taken into account).

 

When emhttp was coded up I looked at apache to see how they handled header lines.  In the code I looked at the max length was set at 1024 and so that's what I set for emhttp.  It turns out cookies can be up 4093 bytes:

http://stackoverflow.com/questions/640938/what-is-the-maximum-size-of-a-web-browsers-cookies-key

(4093 is common but according to RFC they can be arbitrarily sized).

 

When emhttp header line buffer size is reached it treats this as an error condition and closes the connection.  But now every time you click Refresh the browser issues the same GET request with the same long cookie, with the same result (looks like browser is hung).  You should be able to test this theory by firing up a different browser, or connect via different PC and find that webGui is still working.

 

If this is the case, then I will add necessary code to fix this.

 

BTW, the unRaid webGui does not generate or store any cookie data.

 

Yep this could be a very nice fix indeed