Show HN: Human Headers | Hacker News Reader

Show HN: Human Headers

github.com

25 pointsrandomdrake17 comments

At first, I liked this idea. It's an ego boost. But then I realized this extra HTTP header information is going out with every request, and really only serves to increase bandwidth. Yes, I know, what's 72 more bytes per request? Still. With humans.txt, the request is on demand.

Great point.

With the goal being that this can run in your browser as you browse the web, would it be more expensive to make an additional entire HTTP request to a, possibly non-existent, humans.txt for every single domain? Or simply pass additional bytes along?

In the discussion on github[1] I raised the suggestion of possibly having the browser extension pass a special accepts or requests header so that it's only passed for people who have the extension installed. Then a simple conditional would be used for the server configuration instead of a statement.

Does that satisfy concerns with "bloat" or are there other considerations, do you think?

[1] - https://github.com/randomdrake/human-headers/issues/1

Nice idea, there is always humans.txt (which a surprising number of sites have, try google for example).

http://humanstxt.org/

This idea was partially inspired by the humans.txt idea. Something that you could just install in your browser and leave on as your browse the web.

By configuring it at the header level, it makes it pretty easy to simply apply it to all HTTP requests.

This allows the info to be parsed whether it's coming from an API response, or a website response, or anything else.

To me this shouldn't be a header. Why not create something like humans.txt? Better to do something you can opt into, instead of jamming an extra header on some guys poor cellular connection.

There's nothing preventing anyone from jamming extra headers onto some guy's poor cellular connection. There's also nothing preventing competent developers from making sure this header isn't implemented in a way that it would affect endusers poorly.

Maybe it's only on a single page? Maybe just some developer documentation? Maybe an API endpoint?

No one is saying how this should be implemented, or even if it is the best idea. It's just a PoC and an idea to share amongst developers.

To be honest, I don't understand your reply. I was merely making a suggestion to avoid using headers for unnecessary data.

"No one is saying how this should be implemented, [...]". The project is called "human-headers". I don't see the need to point out what the goal of the proposition is.

Why not put this information in the html? Then it's only available on one page.

There's a little page here that also links to the chrome extension:

http://www.humanheaders.org

What's wrong with putting this kind of information on the site's "About" page, which doesn't require any special browser extension to display?

Absolutely nothing! Human Headers is intended to be in the same spirit as putting "are you reading this? we're hiring!" in an HTML comment in your source, or the X-Bender header that used to be part of Slashdot responses. It's a fun little thing.

Well, I can think of a couple reasons:

What developers want to communicate to one-another is often not the best material for an about page.

Many (if not most) organizations do not feature all of their development staff on their about page.

Organizations that do feature developers on their about page rarely attribute what things they developed in the organization.

Developers don't just create things for organizations with about pages.

Do developers wish that organizations were better about this? Sure!

OK, I see what you're saying. But if an organization doesn't want their developers sharing this kind of information on their main web site, wouldn't they also object to developers setting up what's essentially their own hidden web page? Do you expect that developers will seek corporate approval before adding these headers?

I would guess it would depend on the organization.

I would also guess it would depend on the developer.

I'm not an organization and this isn't an implementation. It's just a possibility.

I'm with the others who mentioned humans.txt. No header overhead (little as it is), no need to have access to the web server (apache, nginx, etc) (how many professional devs are also their own sysadmin?).

If you want to build a plugin to display the info when you surf the web, make it read humans.txt as that is already in the wild.

I can smell a little bit Semantic Web flavor, but this solution made it more automatic. But using a plug-in sounds like too much.

About Semantic Web, I've got a short report here: http://bit.ly/JP3KQO. Drop me a line if you have comment.

Hmm, human headers. I like it.

Reply on news.ycombinator.com