Display: Full Articles



  • I know I'm not the only person who can't get Display: Full Articles to stick, but now it's my turn. The setting is held in a cookie:

    Name: HPDISPALL
    Content: Y
    Domain: .thedailywtf.com
    Path: /
    Send For: Any type of connection
    Expires: at end of session

    The offending code:

        <script type="text/javascript">
            function setDisp(disp)
            {
                var exp = new Date();
                exp.setDate(exp.getDate()+365);
                document.cookie = 
                    "HPDISPALL=" + (disp?"Y":"N") + 
                    "; domain=.thedailywtf.com" +
                    "; expires=" + exp.toGMTString();
                window.location = '/';
            }
        </script>

    The code appears to work -- the cookie expiry date generated (from .toGMTString()) is one year into the future. But something is stopping the expiry date from sticking. My Firefox cookies window is stacked out with garbage, so every other site is able to generate long-lasting cookies. I can't find anything in Firefox that would stop JavaScript creating permanent cookies, and this worked fine up until the new site style.

    Any suggestions?



  • Never worked for me. IE7/Safari/FF3



  • Well, you can see the cookie above. Since you have Firefox, you could install Edit Cookies and make sure that the cookie is set up properly. I was thinking, what browsers all need is the ability to edit cookies and checked -- Firefox has the appropriate add-on. A horribly ugly way to do it, but it exists.

    That said, when I restarted Firefox to install the above add-on, the cookie came back correctly. But if it ever does get eaten, I can now put it back!



  • @Daniel Beardsmore said:

    Well, you can see the cookie above. Since you have Firefox, you could install Edit Cookies and make sure that the cookie is set up properly. I was thinking, what browsers all need is the ability to edit cookies and checked -- Firefox has the appropriate add-on. A horribly ugly way to do it, but it exists.

    That said, when I restarted Firefox to install the above add-on, the cookie came back correctly. But if it ever does get eaten, I can now put it back!

     

    Sorry, but that sounds like WAYYYYY more work than just clicking the 'Full Article' link.

    It doesn't seem to work, but I am not losing sleep over it.



  • For the domain attribute to apply it must have two dots/periods so as not to allow the cookie to apply to all top-level domains such as .com. However, you'll note that the main site is now http://thedailywtf.com, with a hostname of thedailywtf.com in the server response. It seems both IE7 and Firefox 2 clear down the cookie association when they can't match the domain ending ".thedailywtf.com" to "thedailywtf.com". The simple solution is to remove the domain attribute when setting the cookie. There's not really any workaround as the next time you visit the site the server response reaffirms the .thedailywtf.com cookie.

    This should be fixed as I, like many others, click the 'Full Articles' link each time I visit the site in a new browser session - incurring one more page hit to the server than is necessary.



  • @pinkduck said:

    For the domain attribute to apply it must have two dots/periods so as not to allow the cookie to apply to all top-level domains such as .com.
     

    What imposes that restriction? Because that is TRWTF. There is a known, finite list of allowed TLDs and country codes (it changes, but not often). So just prevent cookies from applying to them.



  • @m0ffx said:

    What imposes that restriction?
     

    I think it was IE that started this. It was found that national domains that imposed their own second level "TLD" (ie: .co.uk) could leak cookies at this secondary TLD level, even though the site was (say) acme.co.uk, as .co.uk would fulfill IE's cookie matching requirements, even though it quite obviously had nothing to do with the site in question.

    @m0ffx said:

    (it changes, but not often)

    At the time this stuff occured, Windows Update and the like weren't practical solutions. So it was easier for MS to just make the requirement be two periods, rather than try to keep a list of known secondary TLDs in-browser and hope people would check for updates.


  • ♿ (Parody)

    @pinkduck said:

    For the domain attribute to apply it must have two dots/periods so as not to allow the cookie to apply to all top-level domains such as .com. However, you'll note that the main site is now http://thedailywtf.com, with a hostname of thedailywtf.com in the server response. It seems both IE7 and Firefox 2 clear down the cookie association when they can't match the domain ending ".thedailywtf.com" to "thedailywtf.com". The simple solution is to remove the domain attribute when setting the cookie. There's not really any workaround as the next time you visit the site the server response reaffirms the .thedailywtf.com cookie.

    This should be fixed as I, like many others, click the 'Full Articles' link each time I visit the site in a new browser session - incurring one more page hit to the server than is necessary.

    Aside from changing the domain name from wtf to tdwtf, the code didn't change - it set the domain just like that. Has it just not been working for like 6 months?

    That said, the Authentication Cookie domain is set to ".thedailywtf.com", so that the cookie is shared between Forums and Main site. Any idea why that works (and is remembered), but this doesn't seem to?



  • The preference for remembering to display articles has been broken for a number of months. I originally told you around the middle of last year :) I suspect the forums side of things works because forums.thedailywtf.com fulfils the dot-two requirement somehow. I don't entirely understand what's going on with the cookie management by IE and Firefox though.



  • @Alex Papadimoulis said:

    Aside from changing the domain name from wtf to tdwtf, the code didn't change - it set the domain just like that. Has it just not been working for like 6 months?

    Not entirely true. The Full Article link has been flaky in the past, but it totally borked out with the theme change. It was still working for the most part after the initial switch back to TDWTF. I'm not stating that you changed the code used for that functionality, but that's what I've observed. It consistently refuses to remember the setting ever since the theme change.

    Also, look at the "In reply to" links here. Notice something missing?



  • I just miss the "quote" button. :(



  •  @rbowes said:

    I just miss the "quote" button. :(

    ??? Aside from the one right above the editor?


  • Discourse touched me in a no-no place

     What quote button?

    [IMG]http://i256.photobucket.com/albums/hh189/PaulJHerring/wtf_quote.png[/IMG] 



  • @rbowes said:

    I just miss the "quote" button. :(

     

    You mean the one I just used to quote you?

    I actually think the quote button is great in its' new location. I haven't seen any posts that say "Why didn't it quote when I hit reply?" or "Damn! I mean to quote <so-and-so>."

    Of course, now we get to see all of the posts complaining about the (not) missing quote button. <g> 



  • @KenW said:

    @rbowes said:

    I just miss the "quote" button. :(

     

    You mean the one I just used to quote you?

    I actually think the quote button is great in its' new location. I haven't seen any posts that say "Why didn't it quote when I hit reply?" or "Damn! I mean to quote <so-and-so>."

    Of course, now we get to see all of the posts complaining about the (not) missing quote button. <g> 

     

    Not to mention this selective quoting feature. I love that.



  • One day later, it's still working for me. The cookie matching (".thedailywtf.com") doesn't appear to be the problem, just that something was causing the cookie to expire at the end of the session. I'd just put it down to bizarre bugs in Firefox except that it also happens outside of Firefox, which is the strange part.

    I also have no idea why the cookie fixed itself. The cookie window clearly showed end-of-session expiry (see table in first post) and I was playing around with the JavaScript in Firefox's Error Console. I never executed "document.cookie", just alert() on the date and string generation to ensure that it was generating correct cookie data. Something in doing that acted like it went over and put the cookie right, which makes even less sense.

    It would seem though that as long as the cookie expiry date is correct, it works. All browsers should at least have a cookie display window, so you can use that to check what the cookie is doing.



  • @Daniel Beardsmore said:

    I'd just put it down to bizarre bugs in Firefox
     

    THERE ARE NO BUGS IN FIREFOX!!!!

    Geez...



  • The expiration date is definitely not working. I double-checked my cookies. The expiration for the HPDISPALL one is showing 1969-12-31 19:00:00 whereas the other 6 cookies from this site are correctly dated 1 month to 1 year into the future. If I change the date and reload the front page, it changes it back. As an FYI: I'm using Opera 9.24



  • @Daniel Beardsmore said:

    The code appears to work -- the cookie expiry date generated (from .toGMTString()) is one year into the future. But something is stopping the expiry date from sticking.

    From what you say I gather that the "getDate" function should be the only thing actually setting the "HPDISPALL" cookie. However:

    C:\> lwp-request -mHEAD -H"Cookie: HPDISPALL=Y" http://thedailywtf.com
    200 OK
    Cache-Control: no-cache
    Date: Thu, 31 Jan 2008 16:39:36 GMT
    Pragma: no-cache
    Server: Microsoft-IIS/6.0
    Content-Length: 53915
    Content-Type: text/html; charset=utf-8
    Expires: -1
    Client-Date: Thu, 31 Jan 2008 16:39:35 GMT
    Client-Peer: 74.50.106.245:80
    Client-Response-Num: 1
    Set-Cookie: HPDISPALL=Y; domain=.thedailywtf.com; path=/
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET

    It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.



  • @Michael Buschbeck said:

    It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.

    Nice troubleshooting job. If only our SysOps could do things like that...


  • ♿ (Parody)

    @Michael Buschbeck said:

    @Daniel Beardsmore said:

    The code appears to work -- the cookie expiry date generated (from .toGMTString()) is one year into the future. But something is stopping the expiry date from sticking.

    From what you say I gather that the "getDate" function should be the only thing actually setting the "HPDISPALL" cookie. However:

    C:\> lwp-request -mHEAD -H"Cookie: HPDISPALL=Y" http://thedailywtf.com
    200 OK
    Cache-Control: no-cache
    Date: Thu, 31 Jan 2008 16:39:36 GMT
    Pragma: no-cache
    Server: Microsoft-IIS/6.0
    Content-Length: 53915
    Content-Type: text/html; charset=utf-8
    Expires: -1
    Client-Date: Thu, 31 Jan 2008 16:39:35 GMT
    Client-Peer: 74.50.106.245:80
    Client-Response-Num: 1
    Set-Cookie: HPDISPALL=Y; domain=.thedailywtf.com; path=/
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET

    It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.

    Brilliant! I fixed the server side code... hopefully. Anyone want to confirm?



  • @Alex Papadimoulis said:

    @Michael Buschbeck said:

    @Daniel Beardsmore said:

    The code appears to work -- the cookie expiry date generated (from .toGMTString()) is one year into the future. But something is stopping the expiry date from sticking.

    From what you say I gather that the "getDate" function should be the only thing actually setting the "HPDISPALL" cookie. However:

    C:\> lwp-request -mHEAD -H"Cookie: HPDISPALL=Y" http://thedailywtf.com
    200 OK
    Cache-Control: no-cache
    Date: Thu, 31 Jan 2008 16:39:36 GMT
    Pragma: no-cache
    Server: Microsoft-IIS/6.0
    Content-Length: 53915
    Content-Type: text/html; charset=utf-8
    Expires: -1
    Client-Date: Thu, 31 Jan 2008 16:39:35 GMT
    Client-Peer: 74.50.106.245:80
    Client-Response-Num: 1
    Set-Cookie: HPDISPALL=Y; domain=.thedailywtf.com; path=/
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET

    It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.

    Brilliant! I fixed the server side code... hopefully. Anyone want to confirm?

     


  • @Alex Papadimoulis said:

    Brilliant! I fixed the server side code... hopefully. Anyone want to confirm?
     

    I just deleted that cookie and clicked "Full Articles". It now shows as expiration "Friday, January 30, 2009 12:38:11 PM", and it used to be "at end of session". Success!

    And here I was thinking I was the only one who had that problem of the setting not sticking :)



  • @Michael Buschbeck said:

    From what you say I gather that the "getDate" function should be the only thing actually setting the "HPDISPALL" cookie. However: ... It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.

    D'oh! Didn't think of that. Incidentally, I have a program that's the graphical equivalent of lwp-request (that I would have used), but on trying it now I see that it's broken when it comes to cookie domains that start "." -- it doesn't detect that they need to be sent from the cookie jar. Looks like I have another bug to fix :)

    Nice work, and thanks. And to Alex of course.



  • @Daniel Beardsmore said:

    Incidentally, I have a program that's the graphical equivalent of lwp-request (that I would have used)

    Ah! That took a while to sink in. You're Daniel Beardsmore of Telcontar.net fame; I knew your name sounded familiar. I'm a pseudo-regular reader of your "Bug of the moment" pseudo-blog. :-)

    (Oh... and, "getDate"? "setDisp"? The keys are right next to each other. Duh, me.)



  • @Michael Buschbeck said:

    Ah! That took a while to sink in. You're Daniel Beardsmore of Telcontar.net fame; I knew your name sounded familiar. I'm a pseudo-regular reader of your "Bug of the moment" pseudo-blog. :-)

    Fame? Someone actually reads it? Nifty :-P It's slowed right down lately as I've run out of funky bugs. I am not sure whether to be glad and thankful, or upset. I'm not out of ordinary bugs, though, just nothing inspiring.

    (Oh... and, "getDate"? "setDisp"? The keys are right next to each other. Duh, me.)

    You've lost me ...



  • @Alex Papadimoulis said:

    @Michael Buschbeck said:

    @Daniel Beardsmore said:

    The code appears to work -- the cookie expiry date generated (from .toGMTString()) is one year into the future. But something is stopping the expiry date from sticking.

    From what you say I gather that the "getDate" function should be the only thing actually setting the "HPDISPALL" cookie. However:

    C:\> lwp-request -mHEAD -H"Cookie: HPDISPALL=Y" http://thedailywtf.com
    200 OK
    Cache-Control: no-cache
    Date: Thu, 31 Jan 2008 16:39:36 GMT
    Pragma: no-cache
    Server: Microsoft-IIS/6.0
    Content-Length: 53915
    Content-Type: text/html; charset=utf-8
    Expires: -1
    Client-Date: Thu, 31 Jan 2008 16:39:35 GMT
    Client-Peer: 74.50.106.245:80
    Client-Response-Num: 1
    Set-Cookie: HPDISPALL=Y; domain=.thedailywtf.com; path=/
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET

    It seems the webserver itself is generating a "Set-Cookie" header as well, (redundantly) reflecting the cookie value it received from the client, but omitting the "expires" attribute from it. So that's where the client's idea that the cookie should expire when the session ends comes from.

    Brilliant! I fixed the server side code... hopefully. Anyone want to confirm?

    I can't get full articles to show on the main page. Safari 2.0.4 here.


  • If you can't see the full articles at all, ever, then are cookies being blocked somewhere? Clicking Full Articles sets the cookie and then reloads the page, using only the cookie to tell the server to send the full articles. That link cannot and will not function without a minimum of session cookie storage.

    You can go to Preferences → Security → Show Cookies to check that the HPDISPALL cookie for .thedailywtf.com is being stored correctly. It needs to exist and be set to Y for full articles to be shown.

    (I assume you are running Safari 2 instead of 3 on purpose? Safari 3 in 10.4.11 works fine for me.)


    I get the getDate/showDisp thing now, duh.


  • @Daniel Beardsmore said:

    (Oh... and, "getDate"? "setDisp"? The keys are right next to each other. Duh, me.)

    You've lost me ...

    If you re-read my original posting, you'll notice that I was mistakenly referring to some "getDate" function setting the cookie. I actually meant to write "setDisp" there. (I had missed that too until I found my own posting quoted by several other posters.)

    Anyway, I'm glad that cookie issue is solved now; it had been bothering me, too, for a while. Good teamwork indeed. :-)



  • @Daniel Beardsmore said:

    If you can't see the full articles at all, ever, then are cookies being blocked somewhere? Clicking Full Articles sets the cookie and then reloads the page, using only the cookie to tell the server to send the full articles. That link cannot and will not function without a minimum of session cookie storage.

    You can go to Preferences → Security → Show Cookies to check that the HPDISPALL cookie for .thedailywtf.com is being stored correctly. It needs to exist and be set to Y for full articles to be shown.

    Thanks, I fixed it. The problem was that the cookie was being set to "N" on page load, and then not getting over-written when I clicked "full articles". Loading the page, deleting the cookie, and then clicking "full articles" has full articles showing up.

    (I assume you are running Safari 2 instead of 3 on purpose? Safari 3 in 10.4.11 works fine for me.)

    Safari 3 requires 10.4.11. Updating to 10.4.11 requires a reboot, and getting back to where I was before the reboot takes 15-20 minutes.


Log in to reply