Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rip out HTTP 0.9 client support #54920

Closed
pitrou opened this issue Dec 15, 2010 · 13 comments
Closed

Rip out HTTP 0.9 client support #54920

pitrou opened this issue Dec 15, 2010 · 13 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@pitrou
Copy link
Member

pitrou commented Dec 15, 2010

BPO 10711
Nosy @gpshead, @orsenthil, @pitrou, @giampaolo, @merwok
Files
  • removehttp09.patch
  • removehttp09-2.patch
  • removehttp09-3.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2010-12-17.17:37:24.401>
    created_at = <Date 2010-12-15.17:04:57.196>
    labels = ['type-bug', 'library']
    title = 'Rip out HTTP 0.9 client support'
    updated_at = <Date 2010-12-17.17:37:24.399>
    user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2010-12-17.17:37:24.399>
    actor = 'pitrou'
    assignee = 'none'
    closed = True
    closed_date = <Date 2010-12-17.17:37:24.401>
    closer = 'pitrou'
    components = ['Library (Lib)']
    creation = <Date 2010-12-15.17:04:57.196>
    creator = 'pitrou'
    dependencies = []
    files = ['20053', '20061', '20078']
    hgrepos = []
    issue_num = 10711
    keywords = ['patch']
    message_count = 13.0
    messages = ['124032', '124034', '124040', '124043', '124044', '124045', '124046', '124049', '124070', '124113', '124146', '124150', '124234']
    nosy_count = 8.0
    nosy_names = ['jhylton', 'gregory.p.smith', 'exarkun', 'orsenthil', 'pitrou', 'giampaolo.rodola', 'stutzbach', 'eric.araujo']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue10711'
    versions = ['Python 3.2']

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 15, 2010

    Both http.client and http.server claim to support HTTP 0.9. The HTTP 1.0 RFC was filed in 1996, and 1.1 is most commonly used nowadays. We should probably rip off 0.9 support.

    @pitrou pitrou added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Dec 15, 2010
    @pitrou pitrou changed the title Rip off HTTP 0.9 support Rip out HTTP 0.9 support Dec 15, 2010
    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 15, 2010

    Here is a patch.

    @stutzbach
    Copy link
    Mannequin

    stutzbach mannequin commented Dec 15, 2010

    Would it be worth keeping (but modifying) test_http_0_9 to verify that the server complains in the expected way?

    @gpshead
    Copy link
    Member

    gpshead commented Dec 15, 2010

    Ripping HTTP "0.9" support _out_ flys directly in the face of "be lenient in what you accept and strict in what you produce."

    I do not mind removing support from http.server. But http.client needs to be able to communicate with any random server created since the dawn of time. Often on 8 bit microcontrollers that haven't been updated since 1994.

    How does keeping 0.9 client support in hurt us?

    @stutzbach
    Copy link
    Mannequin

    stutzbach mannequin commented Dec 15, 2010

    At minimum, I think we should apply this part of Antoine's patch:

    • Most web servers default to HTTP 0.9, i.e. don't send a status line.

    • default_request_version = "HTTP/0.9"
      + default_request_version = "HTTP/1.0"

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 15, 2010

    But http.client needs to be able to communicate with any random server
    created since the dawn of time.

    Well, that sounds a bit unreasonable...

    Often on 8 bit microcontrollers that haven't been updated since 1994.

    Anyone with such needs should write specialized software, shouldn't they?

    How does keeping 0.9 client support in hurt us?

    In any such situation, there's typically a long-term cost in additional maintenance when patching and improving the code.
    More specifically, this issue came when discussing bpo-6791. Protecting http.client against unbounded reads will be hairy if we have to support HTTP 0.9-style "simple responses".

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 15, 2010

    Would it be worth keeping (but modifying) test_http_0_9 to verify that
    the server complains in the expected way?

    Actually, I don't think the server will complain, since the request is legit. It will send back a full response with status line and headers, though, so the test has to be adapted indeed.

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 15, 2010

    Patch with adapted tests.

    @gpshead
    Copy link
    Member

    gpshead commented Dec 15, 2010

    Given the 6961 issue I'm happy to change my position and say we nuke the 0.9 client support.

    Anyone who _needs_ that can grab this old code or write trivial code for their poor server's needs.

    @orsenthil
    Copy link
    Member

    +1 removing HTTP 0.9, and falling back to HTTP 1.0 behavior where ever it was HTTP 0.9. Removing support for response without status (which was acceptable by 0.9) is fine. I reviewed the patch too and it seems good to go.

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 16, 2010

    I'm opening a separate issue (bpo-10721) for the server side and retargetting this issue to client support. Patch attached.

    @pitrou pitrou changed the title Rip out HTTP 0.9 support Rip out HTTP 0.9 client support Dec 16, 2010
    @merwok
    Copy link
    Member

    merwok commented Dec 16, 2010

    Patch LGTM, modulo warnings.warn calls lacking a stacklevel=2 parameter.

    @pitrou
    Copy link
    Member Author

    pitrou commented Dec 17, 2010

    Patch committed in r87340.

    @pitrou pitrou closed this as completed Dec 17, 2010
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants