intertwingly

Well, an HTML-document's title (in the BODY-HEAD) is relevant even if stored on the local harddrive, authentication headers (in the HEAD-HEAD) are not. It's a matter of scope.

Tomas: including meta http-equiv?

A lot of the web was built very pragmatically.

The http-equiv header is obviously there to make it easier for people to produce HTML documents with HTTP-like functionality without having to get into server-side scripting.

Why should the HTTP server, session and request specific headers be in the body? What would be the purpose? What's pragmatic about that? As far as I see, nothing is.

Tomas: ever see a page which says something to the effect of "you will be redirected in 5 seconds?  Typically, this is implemented via something like the following:

<meta http-equiv="refresh" content="5;url=http://www.example.com">

Is this clean?  Is this a hack?  Is it effective?

No.  Yes.  Yes.

Sam,
  Can you point to a wiki page on this point of contention?

Sam: Yes, I am aware of that.

The difference is that authentication headers are obviously completely useless inside a document, as they are server specific, session specific and request specific. Which, of course, is why there are no authentication headers in HTML either, via meta tags or otherwise.

Creators of HTML documents can add the meta http-equiv header to have the document redirect the browser to an other document, and that works on a locally stored document as well. These headers are document specific, and thus they are/can be tagged to a specific document.

The meta tag, and http-equiv, are motivated by practical use, as you noted. What would be the practical use for putting authentication headers in a document?

Even the name "http-equiv" indicates that they really wanted to be with the rest of the HTTP headers, but couldn't quite get there.

Pragmatism consists of MAY clauses. Our example of http-equiv consists of things that MAY be encapsulated at the next level up. However, there's nothing you can put in an http-quiv that doesn't work as an honest-to-goodness http header.

We'll always have work-arounds, hacks, etc. We'll always NEED them. That's no excuse for not trying to anticipate these scenarios and making things work in an un-hackish manner.

I've had my fill, thanks. I've officially removed my statement of support from the project's Wiki. No, not much of anyone will notice or care, and that's fine... but I'm not gonna add even one tiny scrap of extra momentum to an effort so marked by... [more]

Trackback from Big Damn Heroes (Tech)

PGP is a concrete example of where self-authenticating messages contain signatures in the body.

Despite basic and digest authentication support being built in to virtually every version of every browser, most web authentication schemes are based on simple HTML forms (which result in passwords being sent in the body) and cookies (which have few advocates, yet are widely used).  Where's the  indignation against these techniques?

I will note that all of the existing blogging APIs currently are based on passing authentication information in the payload.  Admittedly, they all have other problems (specifically, they are each susceptible to a replay attack), but these problems aren't based on whether the data is in the header or payload.

People sometimes argue against dispatching based on the payload of a HTTP message.  Try going into a bank and deposit an amount of cash greater than $100,000 US.  You will find that the process is different than the process used when you deposit $100.

I note with amusement that an individual (not Mark!) who previously argued for HTTP authentication noting that it was widely supported by tools, has recently argued in favor of a proposal that involves Atom creating a new authentication mechanism (which would have precisely one existing implementation), even when he knew that the proposal at the time used HTTP incorrectly.  I somehow doubt that any list of tool support for an existing SOAP based authentication mechanism would have changed this individual's mind.

I can provide more examples, but the overall message is that abstractions leak.  As engineers we need to deal with this.

I like REST.  And I like document literal SOAP.  Not simply because of their abstractions, but because their abstractions aren't opaque - i.e., the underlying message in both cases can  be productively processed directly, without the need to resort to a toolkit.

What I don't like is when tools get paternalistic and decide they know better than the developers using these tools.  Authentication is an example where some of the popular tools do exactly that today.

Shortly, I plan to discuss my experiences with the Blogger proposal.  I fully expect this to be met with all the normal rhetoric.  Let me ask in advance that you look past that.

Sam: But, PGP isn't server, session and request specific, either, it's a completely different type of usage.

I guess we could go on forever comparing Atom with other not-so-similar formats and solutions without actually getting anywhere.

But can anyone mention any practical use for putting server/session/request specific authentication headers in the document? What problem does this solve, what functionality does this add?

And all together we think about CUAP

http://www.w3.org/TR/cuap

Dive into Mark has an interesting Who's on First? take on Sam Ruby's <a href='http://www.intertwingly.net/blog/1570.html'>take... [more]

Trackback from Fish Outa Water

HTML 4.01: The HEAD element contains information about the current document, such as its title, keywords that may be useful to search engines, and other data that is not considered document content. User agents do not generally render elements that...

Head-Body is a well known design pattern for markup languages... [more]

Trackback from Don Park's Daily Habit

HTML 4.01: The HEAD element contains information about the current document, such as its title, keywords that may be useful to search engines, and other data that is not considered document content....

Where can I find more information on http_session_id???