curl-library
Re: curl-library Digest, Vol 57, Issue 40
Date: Mon, 17 May 2010 19:18:32 +0530
Hi There,
this is the snippet from wikipage .... caching is described in the last
paragraph
would caching be possible with libcurl, if yes how can this be achieved?
The following example was originally given in RFC
2617<http://tools.ietf.org/html/rfc2617>and is expanded here to show
the full text expected for each request and
response. Note that only the "auth" (authentication) quality of protection
code is covered – at the time of writing only the
Opera<http://en.wikipedia.org/wiki/Opera_(web_browser)>and
Konqueror <http://en.wikipedia.org/wiki/Konqueror> web
browsers<http://en.wikipedia.org/wiki/Web_browser>are known to support
"auth-int" (authentication with integrity protection).
Although the specification mentions HTTP version 1.1 the scheme can be
successfully added to a version 1.0 server, as shown here.
This typical transaction consists of the following steps.
- The client asks for a page that requires authentication but does not
provide a user name <http://en.wikipedia.org/wiki/User_name> and
password. Typically this is because the user simply entered the address or
followed a link <http://en.wikipedia.org/wiki/Hyperlink> to the page.
- The server responds with the
401<http://en.wikipedia.org/wiki/HTTP_401#4xx_Client_Error>response
code, providing the authentication realm and a randomly-generated,
single-use value called a
nonce<http://en.wikipedia.org/wiki/Cryptographic_nonce>
.
- At this point, the client will present the authentication realm
(typically a description of the computer or system being accessed) to the
user and prompt for a user name and password. The user may decide to cancel
at this point.
- Once a user name and password have been supplied, the client re-sends
the same request but adds an authentication header that includes the
response code.
- In this example, the server accepts the authentication and the page is
returned. If the user name is invalid and/or the password is incorrect, the
server might return the "401" response code and the client would prompt the
user again.
Note: A client may already have the required user name and password without
needing to prompt the user, e.g. if they have previously been stored by a
web browser.
------------------------------
*Client request (no authentication)*:
GET /dir/index.html HTTP/1.0
Host: localhost
(followed by a new line <http://en.wikipedia.org/wiki/Newline>, in the form
of a carriage return <http://en.wikipedia.org/wiki/Carriage_return> followed
by a line feed <http://en.wikipedia.org/wiki/Line_feed>).
*Server response*:
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm_at_host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>
*Client request (user name "Mufasa", password "Circle Of Life")*:
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm_at_host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
(followed by a blank line, as before).
*Server response*:
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(followed by a blank line and HTML text of the restricted page).
------------------------------
The "response" value is calculated in three steps, as follows. Where values
are combined, they are delimited <http://en.wikipedia.org/wiki/Delimiter> by
colon <http://en.wikipedia.org/wiki/Colon_(punctuation)> symbols.
1. The MD5 hash of the combined user name, authentication realm and
password is calculated. The result is referred to as HA1.
2. The MD5 hash of the combined method and digest
URI<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>is
calculated, e.g. of
"GET" and "/dir/index.html". The result is referred to as HA2.
3. The MD5 hash of the combined HA1 result, server nonce (nonce), request
counter (nc), client nonce (cnonce), quality of protection code (qop) and
HA2 result is calculated. The result is the "response" value provided by the
client.
Since the server has the same information as the client, the response can be
checked by performing the same calculation. In the example given above the
result is formed as follows – where MD5() represents a function used to
calculate an MD5 hash, backslashes represent a continuation and the quotes
shown are not used in the calculation.
Completing the example given in RFC
2617<http://tools.ietf.org/html/rfc2617>gives the following results
for each step.
HA1 = MD5( "Mufasa:testrealm_at_host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366
Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1
At this point the client may make another request, reusing the server nonce
value (the server only issues a new nonce for each "401" response) but
providing a new client nonce (cnonce). For subsequent requests, the
hexadecimal request counter (nc) must be greater than the last value it used
– otherwise an attacker could simply
"replay<http://en.wikipedia.org/wiki/Replay_attack>"
an old request with the same credentials. It is up to the server to ensure
that the counter increases for each of the nonce values that it has issued,
rejecting any bad requests appropriately. Obviously changing the method, URI
and/or counter value will result in a different response value.
The server should remember nonce values that it has recently generated. It
may also remember when each nonce value was issued, expiring them after a
certain amount of time. If an expired value is used, the server should
respond with the "401" status code and add stale=TRUE to the authentication
header – indicating that the client should re-send with the new nonce
provided, without prompting the user for another user name and password.
The server does not need to keep any expired nonce values – it can simply
assume that any unrecognised values have expired. It is also possible for
the server to only allow each nonce value to be returned once, although this
forces the client to repeat every request. Note that expiring a server nonce
immediately will not work, as the client would never get a chance to use it.
Thanks for you patience :)
Sanjeeth
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-17