Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Probably the worst URL scheme ever

bvb.de

Post reply on HN
Print view View original

31–40 of 106 posts

Re: Probably the worst URL scheme ever

#31

Post by Robin_Message »

ancarda wrote: post #28
cedricd wrote: post #12

The elephant in the room here of course is this: https://news.ycombinator.com/x?fnid=b7VO4wED8MRumCeiX5fCnF

I never understood why HN has such a peculiar URL for accessing pages. It times out after a while too, is that to stop crawlers?

They are ids to lookup closures in a database. They time out to stop the database overflowing ;) It's called continuation-based web development [1], popular with Lisp and Smalltalk-based web servers (because who else has continuations?)

[1] http://en.wikipedia.org/wiki/Continuation#In_Web_development

Re: Probably the worst URL scheme ever

#32

Post by kalmar »

ancarda wrote: post #28
cedricd wrote: post #12

The elephant in the room here of course is this: https://news.ycombinator.com/x?fnid=b7VO4wED8MRumCeiX5fCnF

I never understood why HN has such a peculiar URL for accessing pages. It times out after a while too, is that to stop crawlers?

I believe it's a continuation-style server—hence fnid: function id—and the continuations are only kept around in memory for ~5 minutes.

Re: Probably the worst URL scheme ever

#33

Post by masnick »

joosters wrote: post #20
masnick wrote: post #15

LinkedIn URLs are by far the worst. For example, the first profile that came up when I searched for Paul Graham: http://www.linkedin.com/profile/view?id=23081590&authTyp...

Yes, all those *2s could easily have been optimised into a left shift operator.

Oh so the *2s have some sort of meaning beyond random URL garbage? Please explain! I've always been curious.

Re: Probably the worst URL scheme ever

#36

Post by PavlovsCat »

endgame wrote: post #16
XarotheOne wrote: post #10

Haha that is epic. EDIT: I apologise for the really bad comment. I have read the rules now and will only put high quality posts from now on. Thankyou.

http://thebestpageintheuniverse.net/c.cgi?u=epic

Thank you. I often wanted to write a rant about the epidemic usage of that word, but now I see I don't have to (I can just link to it, like a cow ^^)

Re: Probably the worst URL scheme ever

#38

Post by hosay123 »

dbbolton wrote: post #6

So, this page is named ?_(null)çô(null) ? How does that even begin to make sense?

It's an underscore followed by 4 bytes, possibly the integer 2650072859 or 468186269. If they're intentionally trying to obfuscate their URLs to prevent crawling, it might be further encrypted somehow.

Re: Probably the worst URL scheme ever

#39

Post by franze »

i have seen worse.

i.e. sites that show on page with the url http://www.example.com and another page with the URL http://www.example.com and even after another click the URL http://www.example.com with completely new content

and sites, that use a logic like this http://www.example.com/357893857435/sfjsfsfsfd/this-should-b... where http://www.example.com/357893857435/sfjsfsfsfd/this-is-shoul... and http://www.example.com/357893857435/sfjsfsfsfd/tHIS-is-the-s... show the same page, oh and of course http://www.example.com/357893857435/sfjsfsfsfd also shows the same page.

oh, and cases where http://www.example.com/click1/click2/click3/item-id/123 show the same page as http://www.example.com/click1/item-id/123 which show the same page as http://www.example.com/click1/click2/click3/click4/item-id/1...

all of the examples above are far worse than bvb.de

Re: Probably the worst URL scheme ever

#40

Post by lucian1900 »

kalmar wrote: post #32
ancarda wrote: post #28

Earlier quoted context omitted.

I never understood why HN has such a peculiar URL for accessing pages. It times out after a while too, is that to stop crawlers?

I believe it's a continuation-style server—hence fnid: function id—and the continuations are only kept around in memory for ~5 minutes.

I never understood why the continuation couldn't instead be addressed by a URL path. It could even get constructed from URL/query data if it moves out of memory, so keeping them in memory would only be a caching mechanism.
Post reply on HN