It’s just data

Secure Business Data Interchange Using HTTP

James Clark: My conclusion is that there’s a real need for a cache-friendly way to sign HTTP responses. (Being able to sign HTTP requests would also be useful, but that solves a different problem.)

Perhaps RFC 4130 would be a good starting point.


Conditional GET could solve a small bit of this when sending the same data to the same client (although it depends on smarts on both ends, as well as not scaling to solve sending the same data to multiple clients). Or does ETags work differently over SSL?

I tried to use my http://waffle.wootest.net/ OpenID, but after logging into my OpenID provider and trusting intertwingly.net, I got this error when I was redirected back:

traceback:Traceback (most recent call last):
  File "gateway.cgi", line 47, in ?
    identity.validate(dict(cgi.parse_qsl(os.environ['QUERY_STRING'])))
  File "/home/rubys/mombo/identity.py", line 57, in validate
    file = writeComment(session['parent'],title,body)
  File "/home/rubys/mombo/post.py", line 240, in writeComment
    raise Exception(message)
Exception: POST limit exceeded
Posted by Jesper at

Jesper, you make a good point.  SSL simply makes the data stream opaque to intermediaries.  HTTP caching that is performed at the end points still may be useful — and in many scenarios this is sufficient.

As to temporarily identifying you as a spammer, that clearly is a bug that I haven’t been able to track down as of yet.  I added some additional logging logic to my server so perhaps I can gather more information on this problem in the future.

Posted by Sam Ruby at

I’ve started toying around with some of these ideas in the Abdera security module.  There are servlet filters in place to do conditional XML Encryption and signing of responses.  I have not yet explored the use of multipart messages (e.g. multipart/signed) but I doubt that it would be all that difficult to support.

Posted by James Snell at

Follow up on the Comment from James (Snell!) here: [link] James, When you do get to updating Abdera for multipart stuff, please try MIME4J first!. In other words stay...

Excerpt from Many Hats at

S/MIME is not for Mail Only

James Clark thinks there’s a real need for a cache-friendly way to sign HTTP responses — to get the benefits of HTTP caching while ensuring integrity. Sam Ruby points to RFC 4130 , which explains how to combine S/MIME with HTTP: The...

Excerpt from Stefan Tilkov's Random Stuff at

Interesting......

Excerpt from Talideon.com Linklog at

I added some additional logging logic to my server so perhaps I can gather more information on this problem in the future.

I have did, indeed, find a bug.  One that would only affect people using OpenID.

Posted by Sam Ruby at

Why not S/MIME?

A couple of people have suggested S/MIME as a possible starting point for a solution to signing HTTP documents. This seems like a suboptimal approach to me; I’m not saying it can’t be made to work, but there are a number of things that make me feel...

Excerpt from James Clark's Random Thoughts at

Add your comment