Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
5461
Archived fixes / Re: Buggy Feed links
« on April 16th, 2012, 03:11 PM »Then it WILL break.
The default in PHP itself is &, as per http://[url]http://php.net/manual/en/ini.core.php#ini.arg-separator.input[/url] and the choice to use ; is for avoiding all kinds of nightmares. QueryString.php, line 81 onwards.
That code block is about providing compatibility with & (which it doesn't do entirely because it doesn't change links in the HTML afaik..??), and fixing other things.
So we have to leave that code in, unless you plan on fixing every URL to not use ; (and with all the other problems related to it).
SMF and Wedge using ; is a definite oddity though it does solve so many problems.
I can think of multiple reasons why it might be different between the two.
Either way, the bottom line is that it wasn't and while I have patched around it, I'm not happy with it (which is why I haven't yet committed it)
Note that SID containing a & is injected by SMF and Wedge, and I have no idea why ; wasn't used there.
I suspect that's a leftover from an old version.
Sometimes, you need to re-break things to understand what they tried to fix in the first place.
Sure that's the case. Hence having feeds never contain a session id - and also why I was so adamant about fixing the canonical URL link as well, which also got SID added into it.
The whole thing about using SID in URLs is an interesting one and one I've been unwilling to make a move on because I'm inclined to think that having 'probably accurate' stats about the number of guests is probably slightly more important than having an SEO benefit to it (though having a canonical URL should fix most issues)
If anything, it's actually more accurate to calculate things this way -- different IPs, rather than different sessions.
Posted: April 16th, 2012, 03:09 PM
Actually, it's worse than that. When this topic kicked off and I threw it at the validator, that error it was giving relates to the fact that there were *malformed* entities in the data, namely amp without the trailing ; in it, where injected by this code.
Previously, it was first removing & at the end and then removing ; or whatever.
When I noticed that, I simply asked Wedge to remove & (without the semicolon) from the URL...
And then I ended up completely removing it. Because it smelt bad.
5462
Features / Re: New revs
« on April 16th, 2012, 02:45 PM »
rev 1549
(4 files, 4kb) (forgot to report it, did it this morning actually...)
+ Added enableError404Logging option (disabled by default), to determine whether the admin really wants to log all Error 404 messages. Probably needs some kind of help text but I'm not even sure my English for the option itself is proper... (ManageSettings.php, ManageSettings.language.php, QueryString.php)
* Some minor optimizations, and starter code for /board/do/action support (will still work as always in the current SVN, it just needs some extra code from the PURL filters which I can't commit until I'm done with the tons of things I've been working on this week... -_-) (QueryString.php)
(4 files, 4kb) (forgot to report it, did it this morning actually...)
+ Added enableError404Logging option (disabled by default), to determine whether the admin really wants to log all Error 404 messages. Probably needs some kind of help text but I'm not even sure my English for the option itself is proper... (ManageSettings.php, ManageSettings.language.php, QueryString.php)
* Some minor optimizations, and starter code for /board/do/action support (will still work as always in the current SVN, it just needs some extra code from the PURL filters which I can't commit until I'm done with the tons of things I've been working on this week... -_-) (QueryString.php)
5463
Archived fixes / Re: Profile error
« on April 16th, 2012, 02:41 PM »It's not even Ikea, it's 'Argos', which is the cheaper and nastier version (but the furniture, if it has all the parts, is usually OK) - currently waiting for delivery, having now moved everything out of my room.
(Oh, and my logic bug was also the main reason why the action rewriter was 3x slower... Oops. Now it's probably no more than 2x slower, although I haven't benchmarked it.)
5464
The Pub / Re: The Cookie Law (in the UK at least)
« on April 16th, 2012, 12:47 PM »It might not, but there is always the possibility that it *does*.
5465
Plugins / Re: Light URL Plugin Maybe?
« on April 16th, 2012, 12:43 PM »Yeah that sounds like a good idea... If I understand correctly, Starting the hash off with T for topic then hash for unique ID.
This can be installed in any directory and will give the short URL stating that directory.
So having like site.com/go/T-774h would suit, if I got it right lol.
Of course, it only saves 3 bytes even for a 6-byte-long post ID...
So I don't know if it's THAT cool in real conditions. But I certainly like having "/go/" because it perfectly complements the default "/do/" (which can be redefined) for action URLs ;)
5466
Archived fixes / Re: Profile error
« on April 16th, 2012, 12:37 PM »
Fixed. Was a logic bug within the action filter.
(iiiiiiiiiiiiiiiiikea! <Chandler Bing voice>)
(iiiiiiiiiiiiiiiiikea! <Chandler Bing voice>)
5467
The Pub / Re: Starting date of the topic in the subject index
« on April 16th, 2012, 12:36 PM »
Hmm well, we could do it on hover or something though...
5468
Archived fixes / Re: Profile error
« on April 16th, 2012, 10:51 AM »
Oh... Right! So it's your OWN profile :)
Quick fix would be to simply manually remove the '/do/profile/' in the URL -- I reproduced that, I'll look into it. It's obviously a bug in my recent PURL changes.
Note to Pete -- QueryString is broken in SVN, I added a parenthesis at the wrong place... I fixed it locally obviously, and it will be in my next commit, but at the rate I'm doing commits, it probably won't be immediately... I'm really upset that I'm so sick that it seems to have an influence on my ability to commit clean code... :(
Quick fix would be to simply manually remove the '/do/profile/' in the URL -- I reproduced that, I'll look into it. It's obviously a bug in my recent PURL changes.
Note to Pete -- QueryString is broken in SVN, I added a parenthesis at the wrong place... I fixed it locally obviously, and it will be in my next commit, but at the rate I'm doing commits, it probably won't be immediately... I'm really upset that I'm so sick that it seems to have an influence on my ability to commit clean code... :(
5469
Archived fixes / Re: Profile error
« on April 16th, 2012, 10:19 AM »
If it's no longer happening to you, then it's fixed... Innit? :P
Seriously, I broke tons of things these days to make way for the PURL changes. (Which ultimately saves about 0.1s of processing time per page... It may not sound like a lot, but it adds up...!)
Seriously, I broke tons of things these days to make way for the PURL changes. (Which ultimately saves about 0.1s of processing time per page... It may not sound like a lot, but it adds up...!)
5470
Plugins / Re: Light URL Plugin Maybe?
« on April 16th, 2012, 09:27 AM »
I think for auto-tiny urls it's best to offer something like:
Site.com/go/hash
Where hash would be a letter indicating content type (t for topic?) and the Id encoded to take less space (base64-like).
That would enable plugins to add more content types, too.
Site.com/go/hash
Where hash would be a letter indicating content type (t for topic?) and the Id encoded to take less space (base64-like).
That would enable plugins to add more content types, too.
5471
Archived fixes / Re: Buggy Feed links
« on April 16th, 2012, 08:34 AM »
(Post written last evening... Axed because of GF axing me for being late :^^;:)
My current implementation has the index.php remover disabled if no cookie is set. This is (was) because the session ID injector wouldn't correctly identify static cache files as static, and would inject the SID into the names.
So I rewrote it to correctly test for a question mark or nothing at all (this was complicated by the fact I had to ensure there wasn't already a SID in the URL.) I'm not sure this is best. Instead of \\?? after the SID test (beginning of ob_sessrewrite), which is already a bit of a buggy thing (you only need to escape the question mark once... it'll still work though, it's just a waste!), I added (?:\?|(?=")), meaning, "either followed by a question mark or a double quote", so it should always inject to homepage links too. Dunno if it's going to be very fast... So maybe I should just not care and simply insert index.php links to cookieless guests..?! (They'll still be transformed to /? if the remover is enabled! Only homepage links won't.)
Links to the homepage are annoying for another reason... As they're not treated by purls, we always end up with a ";" at the end, the one that's injected by the SID test... (Currently '&' in SVN, which is even worse... Or maybe it isn't so? I remember removing a test against & which was probably done for that reason...?)
My current implementation has the index.php remover disabled if no cookie is set. This is (was) because the session ID injector wouldn't correctly identify static cache files as static, and would inject the SID into the names.
So I rewrote it to correctly test for a question mark or nothing at all (this was complicated by the fact I had to ensure there wasn't already a SID in the URL.) I'm not sure this is best. Instead of \\?? after the SID test (beginning of ob_sessrewrite), which is already a bit of a buggy thing (you only need to escape the question mark once... it'll still work though, it's just a waste!), I added (?:\?|(?=")), meaning, "either followed by a question mark or a double quote", so it should always inject to homepage links too. Dunno if it's going to be very fast... So maybe I should just not care and simply insert index.php links to cookieless guests..?! (They'll still be transformed to /? if the remover is enabled! Only homepage links won't.)
Links to the homepage are annoying for another reason... As they're not treated by purls, we always end up with a ";" at the end, the one that's injected by the SID test... (Currently '&' in SVN, which is even worse... Or maybe it isn't so? I remember removing a test against & which was probably done for that reason...?)
5472
Archived fixes / Re: Buggy Feed links
« on April 15th, 2012, 11:45 PM »
Hmm... Double-checked the Noisen codebase, and it doesn't have anything different in that respect... Which is probably why I was so positive Wedge didn't have the problem either.
Anyway, now that we're sure it's never gonna happen... I can safely move back to working on PURLs ;)
Anyway, now that we're sure it's never gonna happen... I can safely move back to working on PURLs ;)
5473
Archived fixes / Re: Buggy Feed links
« on April 15th, 2012, 11:41 PM »
@0x> It SHOULD be working now... I made a test with Google Reader and it no longer shows PHPSESSID links :)
I took the lazy way out really... Added a context variable in Feed.php to say we don't want to insert the session ID. This is tested against in Subs-Template.php. The reason why I was lazy for it, is that (1) just testing for Feedfetcher-Google (or whatever it's called) isn't going to do any good for other feed reader bots, (2) there is VERY little reason to have a session ID in a feed URL. If you have cookies disabled, then your session won't be active forever. Your feed reader will soon end up trying to access an incorrect session ID anyway.Quote from Arantor on April 15th, 2012, 05:58 PM So.. What do we do, eh!Quote I'm aware of how SMF/Wedge deals with it. But I can't find of any (good) reason to disable the ability to specify a new argument separator. I for one never heard of such a case... And I don't even think it would make a forum work because we're assuming pretty much everywhere that ; is the separator, and using it in links... And I don't seem to remember Wedge parsing all links to replace ; to & manually ;) (Not only that, but it's silly to assume that adding & will work everywhere... If a link is inside CDATA tags, then you're screwed!)
I would be tempted to say that we should remove that compatibility code...Quote And we should have dealt with that long ago. Seriously, I'm surprised we had the problem at all, because if you'll look at noisen.com, the phpsessid is never injected *at all* into feeds...
I took the lazy way out really... Added a context variable in Feed.php to say we don't want to insert the session ID. This is tested against in Subs-Template.php. The reason why I was lazy for it, is that (1) just testing for Feedfetcher-Google (or whatever it's called) isn't going to do any good for other feed reader bots, (2) there is VERY little reason to have a session ID in a feed URL. If you have cookies disabled, then your session won't be active forever. Your feed reader will soon end up trying to access an incorrect session ID anyway.
There is a (valid) argument about rejecting those cases and disallowing it entirely for security reasons.Quote Of course, there's still the problem of browsers that disable cookies entirely... i.e. if you're logged in and have cookies disabled like me right now, you absolutely need a phpsessid link in the URL.
Because & is the argument separator defined in PHP's configuration. Check the code in QueryString, if ; is arg-separator, it does one thing, but otherwise, it does something else to manually parse out the parameters. ; is just not the default. But we get cases, just for fun, of malformed entities being prepared occasionally too.
I would be tempted to say that we should remove that compatibility code...
Seriously, it IS injecting PHPSESSID. It does it on the RSS validator. I have no idea what user agent Google Reader uses but I'm willing to bet it doesn't trip possibly_robot. It's actually irrelevant in this case. It does not matter whether it trips possibly_robot or not, it should NEVER be issuing PHPSESSID in feeds, ever, because some other feed readers will choke on non unique URLs, I know Thunderbird used to have issues with it, for example (because that didn't bother with cookies at one time)
5474
Development blog / Re: This. Is. Crazy.
« on April 15th, 2012, 11:28 PM »
Thank you :) (Dunno how I missed your post!)
5475
The Pub / Re: The Cookie Law (in the UK at least)
« on April 15th, 2012, 11:07 PM »
LOL. This won't last...