Hallo,
Und wenn ich das begriffen habe, dann könnte ich es meinem Server ja beibringen, das genauso aufzubereiten, damit der Client die übersandten Daten dann möglichst wieder mitsendet.
Dass er das nicht so tut, wie erwartet/erhofft, haben wir ja von Christian K. schon vernommen,
Wenn es Dir um Daten der Basic HTTP Authentication geht, dann kommt es drauf an, was Du erwartest. Normalerweise sendet der Client die Anmeldedaten (Nutzer und Passwort) innerhalb einer Browser-Sitzung immer wieder automatisch mit, wenn vom _selben_ Server ein 401 mit einem realm kommt, den der Browser gecached hat. Hierduch muss man sich in einer Sitzung am selben Server nicht mehrfach anmelden, solange sich der realm (der geschütze Bereich) nicht ändert.
http://www.faqs.org/rfcs/rfc2617.html
...
The authentication parameter realm is defined for all authentication
schemes:
realm = "realm" "=" realm-value
realm-value = quoted-string
The realm directive (case-insensitive) is required for all
authentication schemes that issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL (the
absoluteURI for the server whose abs_path is empty; see section 5.1.2
of [2]) of the server being accessed, defines the protection space.
These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, which may have
additional semantics specific to the authentication scheme. Note that
there may be multiple challenges with the same auth-scheme but
different realms.
A user agent that wishes to authenticate itself with an origin
server--usually, but not necessarily, after receiving a 401
(Unauthorized)--MAY do so by including an Authorization header field
with the request. A client that wishes to authenticate itself with a
proxy--usually, but not necessarily, after receiving a 407 (Proxy
Authentication Required)--MAY do so by including a Proxy-
Authorization header field with the request. Both the Authorization
field value and the Proxy-Authorization field value consist of
credentials containing the authentication information of the client
for the realm of the resource being requested. The user agent MUST
choose to use one of the challenges with the strongest auth-scheme it
understands and request credentials from the user based upon that
challenge.
...
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Similarly, when a client sends a request to a proxy, it may reuse a
userid and password in the Proxy-Authorization header field without
receiving another challenge from the proxy server. See section 4 for
security considerations associated with Basic authentication.
...
viele Grüße
Axel