This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author samwyse
Recipients gvanrossum, jerith, samwyse, vila
Date 2008-05-11.02:01:28
SpamBayes Score 0.009771928
Marked as misclassified No
Message-id <9d4553440805101901u20119774i146194945bd2acb9@mail.gmail.com>
In-reply-to <1210448047.58.0.340955792809.issue1491@psf.upfronthosting.co.za>
Content
Although any given implementation of an HTTP server is likely to serve
up its headers in a predicable, repeatable, order, I don't think that
we should specify a particular order in the test suite.  Section 4.2
of RFC 2616 specifically states, "The order in which header fields
with differing field names are received is not significant."  So, I
dislike these (and similar) statements in the patch:

+        self.assertTrue(result[1].startswith('Server: '))
+        self.assertTrue(result[2].startswith('Date: '))
+        self.assertTrue(result[3].startswith('Content-Type: '))

I think it would be better to say this:

+        self.assertEqual(sum(r.startswith('Server: ') for r in
result[1:-1]), 1)
+        self.assertEqual(sum(r.startswith('Date: ') for r in result[1:-1]), 1)
+        self.assertEqual(sum(r.startswith('Content-Type: ') for r in
result[1:-1]), 1)

or even this:

+        # Verify that certain message headers occur exactly once.
+        for fieldName in 'Server: ', 'Date: ', 'Content-Type: ':
+            self.assertEqual(sum(r.startswith(fieldName) for r in
result[1:-1]), 1)

(Note that in test_with_continue_1_1, you'd need to say result[2:-1].)

On Sat, May 10, 2008 at 2:34 PM, Jeremy Thurgood <report@bugs.python.org> wrote:
>
> Jeremy Thurgood <firxen@gmail.com> added the comment:
>
> Added handling for "Expect: 100-continue" header to
> BaseHTTPRequestHandler. By default, any request that has this header
> gets a 100 Continue response (with no other headers) before
> do_WHATEVER() is called. By overriding handle_expect_100(), you can
> reject incoming requests instead of sending a 100 Continue if you so desire.
>
> Refactoring as per comments above was also performed.
>
> Note: This patch changes the default behaviour in the case where both
> the client and the server claim to support HTTP/1.1 from doing nothing
> in the case of an "Expect: 100-continue" header on the request to
> sending a 100 Continue response and then completing the request as normal.
>
> ----------
> keywords: +patch
> nosy: +jerith
> Added file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1491>
> __________________________________
>
History
Date User Action Args
2008-05-11 02:01:39samwysesetspambayes_score: 0.00977193 -> 0.009771928
recipients: + samwyse, gvanrossum, vila, jerith
2008-05-11 02:01:37samwyselinkissue1491 messages
2008-05-11 02:01:35samwysecreate