

Show HN: Human Headers  - randomdrake
https://github.com/randomdrake/human-headers/

======
whileonebegin
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.

~~~
randomdrake
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](https://github.com/randomdrake/human-headers/issues/1)

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

[http://humanstxt.org/](http://humanstxt.org/)

~~~
randomdrake
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.

------
michaelmcmillan
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.

~~~
randomdrake
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.

~~~
michaelmcmillan
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.

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

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

[http://www.humanheaders.org](http://www.humanheaders.org)

------
greenyoda
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?

~~~
randomdrake
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!

~~~
greenyoda
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?

~~~
randomdrake
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.

------
thebouv
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.

------
dclara
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](http://bit.ly/JP3KQO). Drop me a line if you have
comment.

------
Raphael
Hmm, human headers. I like it.

