Ignore:
Timestamp:
Mar 9, 2011, 4:25:45 PM (9 years ago)
Author:
fielding@…
Message:

Discussion on list suggests that userinfo remains in common use
for configuration or command options, so it needs to be defined.
However, we can exclude it from being sent in messages.

Addresses #159

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1156 r1157  
    10571057   The URI generic syntax for authority also includes a deprecated
    10581058   userinfo subcomponent (<xref target="RFC3986" x:fmt="," x:sec="3.2.1"/>)
    1059    for including user authentication information in the URI.  The userinfo
    1060    subcomponent (and its "@" delimiter) &MUST-NOT; be used in an "http"
    1061    URI.  URI reference recipients &SHOULD; parse for the existence of
    1062    userinfo and treat its presence as an error, likely indicating that
    1063    the deprecated subcomponent is being used to obscure the authority
    1064    for the sake of phishing attacks.
     1059   for including user authentication information in the URI.  Some
     1060   implementations make use of the userinfo component for internal
     1061   configuration of authentication information, such as within command
     1062   invocation options, configuration files, or bookmark lists, even
     1063   though such usage might expose a user identifier or password.
     1064   Senders &MUST-NOT; include a userinfo subcomponent (and its "@"
     1065   delimiter) when transmitting an "http" URI in a message.  Recipients
     1066   of HTTP messages that contain a URI reference &SHOULD; parse for the
     1067   existence of userinfo and treat its presence as an error, likely
     1068   indicating that the deprecated subcomponent is being used to obscure
     1069   the authority for the sake of phishing attacks.
    10651070</t>
    10661071</section>
Note: See TracChangeset for help on using the changeset viewer.