Hi,
I've been writing an OAuth 1.0 egg.
One of the ways of passing the OAuth protocol parameters to the server
involves the HTTP Authorization header thusly:
-----
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
-----
The above is a copy/paste from the RFC:
http://tools.ietf.org/html/rfc5849#section-3.1
I want to talk about that word "OAuth" that appears immediately after
"Authorization: ".
HTTP specifies that that word is case-insensitive:
-----
"HTTP provides a simple challenge-response authentication mechanism that
MAY be used by a server to challenge a client request and by a client to
provide authentication information. It uses an extensible,
case-insensitive token to identify the authentication scheme, followed
by a comma-separated list of attribute-value pairs which carry the
parameters necessary for achieving authentication via that scheme."
-- RFC2617, section 1.2
-----
...and therefore when the intarweb egg unparses that header and converts
the auth-scheme from a symbol to a string it also converts whatever is
passed in into title case using intarweb's symbol->http-name.
That is entirely reasonable and conforms with the standard.
However, this results in my OAuth Authorization header looking like this:
-----
Authorization: Oauth oauth_signat...
-----
...and this causes at least Dropbox's OAuth implementation to complain
that the OAuth request is invalid.
To work around this I have patched my copy of the intarweb egg thusly:
(sorry if it doesn't copy/paste well)
-----
diff -upr intarweb.orig/header-parsers.scm intarweb/header-parsers.scm
--- intarweb.orig/header-parsers.scm 2012-10-23 00:09:28.266118261 +0100
+++ intarweb/header-parsers.scm 2012-10-23 00:05:39.071326856 +0100
@@ -823,7 +823,7 @@
(authorization-param-subunparsers)
eq? default-unparser))
(unparsed-value (sprintf "~A ~A"
- (symbol->http-name auth-scheme)
+ (symbol->string auth-scheme)
(unparser (get-params (car
headers))))))
(loop (cdr headers) (cons unparsed-value result))))))
-----
This preserves the case of the symbol passed in by the API user.
Whilst this results in an intarweb that still complies with the
standard, I wonder if there is a better way of tackling this?
Regards,
@ndy
--
[email protected]
http://www.ashurst.eu.org/
0x7EBA75FF
_______________________________________________
Chicken-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/chicken-users
