RE: Implications of introducing new scheme and port for existing HTTP servers

Rob's argument is broadly correct -- as a long term firewall design issue,
method inspection (and occasionally payload inspection) will become the
rule.

However, as a small carrot to today's protocol designers, the vast majority
of the installed base of firewalls do no method / payload inspection on HTTP
data being passed through.   Purely from the perspective of 'reach' there's
no impediment to IPP using it's own method in the short run.

> -----Original Message-----
> From:	Rob Polansky [SMTP:polansky@raptor.com]
> Sent:	Tuesday, June 02, 1998 6:06 AM
> To:	David W. Morris
> Cc:	http-wg; ipp@pwg.org
> Subject:	RE: Implications of introducing new scheme and port for
> existing  HTTP servers
> 
> I know of at least one :-) firewall that not only rejects unknown methods
> but also examines the HTTP request method as part of its "algorithm". From
> a
> protocol and security perspective, it appears to be the right thing to do.
> If you don't understand the method, how can you properly proxy it? Take
> the
> CONNECT method as an example.
> 
> In summary, any proxy that is more than a simple packet passer (supports
> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of
> failing to pass IPP if it uses a new scheme and/or a new method. Not that
> that's a bad thing... :-)
> 
> -Rob Polansky
> 
> > -----Original Message-----
> > From: David W. Morris [mailto:dwm@xpasc.com]
> > Sent: Monday, June 01, 1998 10:34 PM
> > To: Carl-Uno Manros
> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com
> > Subject: Re: Implications of introducing new scheme and port for
> > existing HTTP servers
> >
> > (I'm also not wild about new HTTP methods as I know of existing proxies
> > which will reject unknown methods. Don't know of any which will accept
> > unknown methods. I'm also unaware of any firewall software which
> examines
> > the HTTP request method as part of its algorithm but then I'm not a
> > firewall expert.)
> >

Received on Tuesday, 2 June 1998 08:49:16 UTC