Hacker Newsnew | comments | show | ask | jobs | submit | jewbacca's comments login

> 404 should be reserved for URL/route errors.

What dichotomy are you working off of here? It is absolutely a 404. How is this any less applicable to a DELETE request than it would be to a GET request for the same resource? What extra information would this new status status code carry?


> 10.4.5 404 Not Found

> The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.


Ok, so client requests "DELETE www.company.com/api/thing/1234" and gets a 404. Or even "GET www.company.com/api/thing/1234". Delete vs get doesn't matter.

Did 1234 not exist, or is "/api/thing" the wrong path?

404 is overloaded. It can mean two very different things.

> Did 1234 not exist, or is "/api/thing" the wrong path?

This doesn't matter. You shouldn't be trying to pull "1234" out of the URI. The identifier for the resource as far as the client is concerned is the URI, not some numeric component buried within it. Just treat the URI as an opaque piece of information – if you get a 404, it's the wrong URI. If you're trying to divine meaning from the constituent parts of the URI, then you're almost certainly making a mistake.

Yes, but is it the wrong URI because the path is wrong (and then I'll double check the docs and my code), or was the 404 because the code is correct but the specific item could not be found? All you are saying is "it doesn't matter", which is unhelpful and ignores the fact that these are completely different error conditions.

All server code for REST will be written in terms of /path/to/{ID}. We have a path, we have a instance ID, which each may be incorrect.

> is it the wrong URI because the path is wrong (and then I'll double check the docs and my code)

This is the source of the problem. REST APIs are hypertext-driven. They use links, like the web. You access resources by following links, not by constructing URIs. If you are reading the specification to find out which paths to use, then hard-coding them in your client software, then you don't have a REST architecture, you have something very different (which, unfortunately, some people insist on calling "REST" anyway).

REST revolves around hypertext. You don't hard-code paths, the server provides resources that link to one another. The client accesses the resources by following the links, not by constructing URIs itself.

If you have a REST architecture, then you can't get the path wrong in your client code because the path isn't in your client code. It's in a resource the server gives you.

> All server code for REST will be written in terms of /path/to/{ID}.

Perhaps, but the client should not be aware of this. The ID that a REST client uses is the URI.

> We have a path, we have a instance ID, which each may be incorrect.

The only ID that the client has is a URI, and if you get a 404, it means that there's no resource available for you to access with that ID. The client does not have a path, and the client does not have an instance ID. It only has a URI.

Ah, I think I understand what you're getting at now, that's a really interesting question.

I can't entirely back this up without probably days of reading RFCs, but my initial gut feeling is that making this distinction, which is not really possible in a truly general way (provided the URI is a syntactically correct HTTP URI), would be exposing internal implementation details in a way that would be conceptually inconsistent with other HTTP response statuses.

eg, how to usefully and consistently make the distinction:

    GET /asfd
    200 OK

    GET /qwer
    4XX We don't have that right now

    GET /zxcv
    4XX That is not even a thing
Keep in mind that the RESTful URI style is not part of the HTTP standard in any way. In HTTP, URIs can be random gibberish, even if they refer to "sibling" resources semantically. "You're on the right path" vs "What are you even talking about" is not an inherent concept in HTTP.

It might make sense in certain circumstances of RESTfully-modelled resource URIs layered on top of HTTP:

    GET /users/asfd
    200 OK

    GET /users/qwer
    4XX We don't have that right now

    GET /blarghs/asdf
    4XX That is not even a thing
But to describe this situation in an HTTP response status would be "mixing layers" and making assumptions in a way that opens a conceptually messy can of worms.


Disclaimer: I have no idea what I'm talking about and am not entirely convinced by my own argument. I'm always skeptical of "that's just not how it's done right now"-flavoured arguments, which this doesn't stop smelling like as I attempt to reason about it.


As practical matter, the body of the 404 response can describe the situation within the context of the application. And if your application is smart enough (though to do this in the general case is impossible or would require something like strong AI), you can use any of several more specific responses (Gone, Found, etc; depending on the context) if you're willing and capable of inferring a specific intent from the otherwise bad request.

"is /api/thing the wrong path" - is fixed by hypermedia, so 404 generally means that resource cannot be found.

It's hard to argue about this without some idea about what the original author considers "real"/"not a myth".

If he considers genes to be "real" in comparison (which I cannot totally infer from this piece of writing; but he does seem to put a lot of stock in the identification of a physical mechanism for projecting the idea of genetics onto, in DNA), there's a pretty straightforward map-vs-territory argument to reduce that (and pretty much everything else) to equivalence.

All of thought and semantics are imperfect metaphors. The question "are memes real" is exactly equivalent to "are genes real" is exactly equivalent to "is math real" is exactly equivalent to "are trees real" is exactly equivalent to "is anything in our understanding of reality real".

Short of a physical "theory of everything", the only description of physical reality that is "real" is the total enumeration of all of physical reality.


This is fucking nuts!

All of the game code is Nethack's original C: https://github.com/coolwanglu/BrowserHack/tree/master/src

Porting is mainly accomplished by defining a windowing system for 'web' (mostly in C), right next to the definitions for 'X11', 'Qt', etc: https://github.com/coolwanglu/BrowserHack/tree/master/win

And compiling through LLVM via Emscripten, resulting in a browser-runnable JS target: https://github.com/coolwanglu/BrowserHack/tree/gh-pages.

Absolutely incredible work all around.


That said, fuck tilesets. ASCII graphics master race.


Another interesting technical detail is that the nethack code contains a lot of synchronous stuff, which is generally hard to port to the web (where events must be short-lived). To get around that, the port uses Emscripten's emterpreter-async option to build (as you can see here: https://github.com/coolwanglu/BrowserHack/blob/master/build.... ).

That runs the application in a little interpreter designed for Emscripten output; the interpeter is capable of pausing and resuming code, so synchronous code isn't a problem.

More details on emterpreter here: https://github.com/kripken/emscripten/wiki/Emterpreter


Mirroring your thoughts, Great effort and results on the port, but seeing tilesets has ruined the experience for me. I spent many wasted hours via a telnet session when I should be working on my 3rd year university projects!


Highly recommended related video by the same person (XboxAhoy / Stuart Brown):

"Doomed: The Embers of Amiga FPS"



https://github.com/cn-nytimes/ and https://github.com/greatfire/ host information about and software for circumventing the Chinese government's internet censorship systems -- which, among many other things, blocks access to, eg, Google, and The New York Times.

Apparently they (the Chinese government) are not willing to entirely block Github traffic in the same way (presumably as an important tool for their software industry as well). This DDoS is an attempt to punish Github for not removing this block-circumventing information, and force the inaccessibility of those 2 repos specifically. It is being conducted in such a way that this is readily obvious but plausibly deniable.


At the same time I think the censors do not have the political power to block github all together.

"GitHub is the preferred tool for programmers to learn and connect with the rest of the world," he said in his Chinese-language post. He added that the site supported no political ideology, nor contained any reactionary content. "Blocking GitHub is unjustifiable, and will only derail the nation's programmers from the world, while bringing about a loss in competitiveness and insight."

Lee's post was re-tweeted over 80,000 times on Sina Weibo, and featured in news articles on Wednesday. In another post, he later compared the blocking to trying to catch a mouse by burning the entire house down.



> information about and software for circumventing the Chinese government's internet censorship systems -- which, among many other things, blocks access to, eg, Google, and The New York Times.

The actual impact of the attack was to have thousands of news outlets and discussion forum sites mention and link to the github repos that offer circumvention.

Further, by attacking Github, it's guaranteed that many of the most tech-savvy Chinese internet users will have the existance of the forbidden repos launched into their consciousness.

Of course the Chinese government knows this and was likely not responsible for the attack.

The attack would not be possible to commit by the actual perpetrator if there weren't such a knee-jerk bias against the Chinese government's internet censorship.

Let it also be noted that the US Government censors lots of information too, both through so-called "official secrets" requiring security clearance granted by party members, and via laws that crack down on things deemed morally wrong, as well as illicit drugs.


I'm not sure why you are being downvoted; I think differing opinions are the heart of HN.

> so-called "official secrets" requiring security clearance granted by party members

It appears that you're not from the U.S. or another Western-aligned country, security clearances aren't granted to or by the dominant political parties, but are an artifact of government and military/defense industry bureaucracy.


> Of course the Chinese government knows this and was likely not responsible for the attack.

This is an example of the logical fallacy of "argumentum ad stultum", or "appeal to stupidty".

It goes like this:

- X would be stupid. - No one would ever do anything stupid. : Therefore no one would ever do X.

There are so many counter-examples to this argument that they hardly bear mentioning. People do stupid things every day of the week and twice on Sundays. Organizations multiply stupidity as often as they moderate it.

It may be that this wasn't the Chinese government, but pointing out that it would be stupid for them to do so is not an argument against it at all.


> People do stupid things every day of the week and twice on Sundays.

While you are correct in pointing out the logical fallacy, there have been several examples of highly likely false-flag cyber attacks lately. The Sony hack is another example, the result of which was the exact opposite of what the state actor alleged to have done the attack wanted.

"Cyber attacks" are a great platform for false flag attacks because it's easy to obtain servers or DDOS drones in any country.

I'd say a good indicator of strategy like this going on is when a defacing attack is accompanied by targeted data breach. Chances are the data breach was the goal, and the defacing the smoke screen.

Many HN readers could stage a cyber attack that would be initially linked to North Korea or China with a few hours of reading/research.



"Cryptopticon" (cf. "Panopticon")


"Cryptonomicon" (Neal Stephenson novel)


Not that this isn't a valuable and fascinating article (and extremely relevant to anyone who connected with that novel), but noted for other inattentive readers who potentially started into it expecting something else.


"Doom and Metal/Rock: A Comprehensive Comparison"



Is this actually true? It's pretty hard to believe, I honestly feel like you pulled it out of your ass, but it's also possible I'm totally out of touch.

This article is a "feature" (not entirely sure what that implies) in a scientific journal (targeted towards a relatively general audience, compared to other scientific journals). Is this particular publication, or this type of publication, known to pay by the word?

Which other publications pay by the word?

Is it more common in some areas of publication than others?

How could such an incentive-perverting mechanism not have died off by now?

Do any companies still pay/evaluate their developers by lines of code written?


I used to work in newspapers and it's still pretty common in that industry. But they also usually give you a word count to hit, so it's not like you can just write yourself a Mercedes.


In my experience, big sites that crank out short articles like the Atlantic online, Slate, and Vice pay a set rate per piece, but longer-form outlets like Aeon and Nautilus pay per word. I've never written for a print-only magazine but I've heard that they still pay per word by and large. And I should add, the academic journals I've written for pay nothing at all!


qmail 1.03 source mirror on github:



Which, in spite of its 'perfection', it should be noted that you should not run unpatched on a public facing server (or at least not qmail-smtpd), lest you become an unwitting backscatter zombie.

I love djb's software, and I love his way of looking at things, but no software stays perfect forever.


Had to look up what a backscatter zombie was; apparently it's what happens when you accept bogus mail (spam) into your mail queue without checking if it is actually deliverable -- thus end up bouncing it once the queue is processed for delivery -- and typically then sending it back to a forged address -- ie: you become a spam gateway (spammers send you email with sender-addresses they want you to try to send spam to...):



Also a potential fragmentation problem:

"Vancouver": https://localwiki.org/vancouver/

"Metro Vancouver": https://localwiki.org/van/

There's a genuinely hard problem in trying to define discrete but sufficiently meaningful localities. People really like clean dichotomies, but locality is fractal.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact