Re: Restricted ports

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Errors-To: sanders@bsdi.com
Message-id: <9308131627.AA18605@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Restricted ports 
In-Reply-To: Your message of Fri, 13 Aug 93 08:11:21 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 13 Aug 1993 11:27:32 -0500
From: Tony Sanders <sanders@bsdi.com>
Status: RO

> Thus wrote: Tony Sanders
> >First off we are only talking about restricting gopher (I hope).
> >HTTP can't talk to SMTP anyway so no point in restricting it.
> 
>    Well, it can - you will get an error message, but you can construct
> your url just as you would a gopher spec - just have a leading
> newline, like this:(newlines inserted for readability)
> 
> http://loopback:25/%20MAIL%20FROM:%3Chttp-user%3E%0D%0ARCPT%20TO:%3Croot
>                    %3E%0D%0ADATA%0D%0AGopher%20is%20not%20secure%21%0D%0A.
>     	    	   %0D%0AQUIT%0D%0A"
> 
>    You will get a "500 Command unrecognized" error, but the SMTP
> server will still accept new commands.
But the %## things aren't expanded in the HTTP URL so you can't send a
valid SMTP command from an HTTP URL.  Have you done otherwise?

> >So please don't use ports other than 80 unless they are over 1024.
> >And browsers should warn users before sending sensitive information
> >(like userid/passwd in the clear) to ports other than 80.
> 
>    Did any methods of authenticaation get discusssed at the W^5?
Only a little bit.  Not much new info.

> A few points/suggestions.  Why are you having the encoding be included
> with every separate format? Wouldn't it make more sense to use the
> Accept-encoding field 3 or 4 times, like this:
> 	*  Accept-encoding: archive/tar ; archive/gtar ; archive/shar 

FYI: archive/tar isn't an encoding, it's a content-type.

This does raise the question of what does Accept-encoding mean and
how does it fit in with Content-transfer-encoding.

> Or am I misunderstanding part of the proposal? If you can accept one
> type of encoding, you should be able to accept it anywhere (ie: a
> uuencoded, compressed, tar file of 3 mac hqx files :)
I would say we should process the Accept: fields in order and use the
previous fields as defaults for the rest of the types.  Does this
violate anyones sensibilities.  The reason the client profile is
attached to the type itself is they could very well be different, e.g.:

   Accept: image/gif; class=color; depth=8; xdpi=85; ydpi=85
   Accept: application/postscript; depth=1; xdpi=600; ydpi=600

This might be because you plan on printing postscript but viewing gif's
Of course, this is a silly example because the server isn't going to do
anything with the postscript information but this gives you an idea of
why the data is per content-type.  We discussed this at WWWWW and decided
to do it this way.

So my question is what the heck is Accept-encoding: for?  Should it
be called Accept-transfer-encoding: and use the MIME transfer encodings
or what?

--sanders