Re: Deploying new expectation-extensions

On Fri, 2008-04-11 at 07:40 +1000, Mark Nottingham wrote:

> Good question; probably best to ask one of the MF guys (Alex CC'ed).
> 
> Alex - do you have user-configurable testing now?

Yes, but the focus of that work was not on HTTP. Regardless of whether
Co-Advisor scripting works here, I am sure we can hack a few custom test
cases in if somebody wants to test a bunch of HTTP proxies for something
outside of MUST-level RFC 2616 requirements.

On the other hand, if we are talking just about a single simple test
case, a custom Perl or Python script can do the job as well. You can
even reuse curl/wget on the client side.

Please let me know if you need some assistance from the Factory.

Thank you,

Alex.


> On 10/04/2008, at 10:44 PM, Charles Fry wrote:
> > Would co-advisor be the right/best way to test what existing proxies
> > do when they receive an unsolicited 103 response?
> >
> > Charles
> >
> > On Thu, Apr 3, 2008 at 8:12 PM, Mark Nottingham <mnot@yahoo-inc.com>  
> > wrote:
> >> See:
> >>  http://coad.measurement-factory.com/
> >>
> >> A representative test is sending a request with
> >>  Expect: 100-continueing
> >>
> >> I don't see how you can read it both ways; e.g.,
> >>
> >>
> >>> This header field is defined with extensible syntax to allow for
> >>>  future extensions. If a server receives a request containing an
> >>>  Expect field that includes an expectation-extension that it does  
> >>> not
> >>>  support, it MUST respond with a 417 (Expectation Failed) status.
> >>>
> >>
> >> [...]
> >>
> >>
> >>>  The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
> >>>
> >>>  return a 417 (Expectation Failed) status if it receives a request
> >>>  with an expectation that it cannot meet. However, the Expect
> >>>  request-header itself is end-to-end; it MUST be forwarded if the
> >>>  request is forwarded.
> >>>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >>
> >>
> >> On 04/04/2008, at 10:47 AM, Charles Fry wrote:
> >>
> >>> Would you mind pointing us to the "related set of tests" which you  
> >>> refer
> >> to?
> >>>
> >>> Also, could you specify just what you imply by passing and failing
> >>> these tests? Specifically, how is correct proxy behavior defined for
> >>> unknown Expect requests (I could see arguments either way based on  
> >>> my
> >>> reading of the HTTP protocol spec)?
> >>>
> >>> thanks,
> >>> Charles
> >>>
> >>> On Thu, Apr 3, 2008 at 7:06 PM, Mark Nottingham <mnot@yahoo-inc.com>
> >> wrote:
> >>>
> >>>>
> >>>> I've tested a fairly wide variety of proxies with co-advisor; the  
> >>>> only
> >> one
> >>>> that passed the related set of tests was very recent builds of  
> >>>> Squid
> >>>> (2.7DEVEL0). Everything else -- including Squid 2.6STABLE4 --  
> >>>> failed (it
> >>>> would take some digging to figure out exactly where this happened,
> >> unless
> >>>> Henrik knows; regardless, I think it's safe to say that a very  
> >>>> large
> >>>> proportion of Squid's installed base fails as well).
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> On 04/04/2008, at 6:01 AM, Julian Reschke wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> interesting:
> >>>>>
> >>>>
> >> <http://code.google.com/p/google-gears/wiki/ResumableHttpRequestsProposal 
> >> >.
> >>>>
> >>>>>
> >>>>> In particular:
> >>>>>
> >>>>> "Note that section 14.20 of HTTP/1.1 indicates that "an HTTP/1.1  
> >>>>> proxy
> >>>>>
> >>>> MUST return a 417 (Expectation Failed) status if it receives a  
> >>>> request with
> >>>> an expectation that it cannot meet". We expect that fully compliant
> >> proxies ignore Expect pragmas which they don't understand (as opposed to
> >> understand but cannot meet), but this remains to be verified in the wild."
> >>>>
> >>>>>
> >>>>> So does anybody know that proxies do here?

Received on Thursday, 10 April 2008 22:13:33 UTC