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.)
> >