Dennis Haney <davh@diku.dk> writes:
> Kim Petersen <kim@vindinggaard.dk> writes:
>
> > Peter Brodersen <professionel@nerd.dk> writes:
> >
> > > On 24 Oct 2001 02:54:22 +0200, Kim Petersen <kim@vindinggaard.dk>
> > > wrote:
> > >
> > > >> >Fordi FTP er en langt mere effektiv protokol ? Og FTP ikke kræver special
> > > >> >software???
> > > >> Hvordan "langt mere effektiv"? Hvis man har en URL, er der mindre
> > > >> overhead med HTTP.
> > > >Hvad er der galt med en FTP URL? ftp://ftp.funet.fi/rfc/rfc2616.txt som jeg
> > > >skulle bruge senere.
> > >
> > > Intet, men har man ligeledes en HTTP-URL, vil der være mindre overhead
> > > ved HTTP, fremfor FTP. Så til det formål er FTP ikke "langt mere
> > > effektiv".
> >
> > Lad os se,
> >
> > 1) Mulighed for rent faktisk at få at vide (computer læsbart) hvilke filer
> > der er tilstede. Deres rettigheder plus muligheden for at rette disse.
>
> Computer læsbart, nej ikke per standard implementation desværre ;(
Faktisk computer læsbart - brug NLST (vi er enige om at LIST ikke er)
>
>
> > 2) Muligheden for at transmitere data mellem to maskiner - hvor ingen af
> > dem er den maskine du sidder på (og kører FTP programmet/sessionen på).
>
> H-vem bruger det? Jeg har personligt aldrig... Jeg finder det MEGET
> nemmere at logge ind på den maskine jeg vil have noget overført til og
> hente det der. Desuden er der mange af de servere der er sat op rundt
> omkring i verden ikke i stand til det.
Det er vist mere et spørgsmål, om implementeringer i din klient end i
serverne, der er ikke noget specielt, i den måde denne feature er imple-
menteret, i forhold til den "normale" måde.
Det er primært (min verden) en måde til at fjernstyre overførsler ved
hjælp af scripts.
>
> > 3) Muligheden for at transmitere binær data uden at "knække" protokollen,
> > (og ja jeg ved at rfc2068 HTTP/1.1 kræver dette - men ikke alle servere
> > håndterer hele rfc2068 afaik - binær og chunks _kræver_ 1.1).
>
> Dette er ikke et problem i den virkelige verden.
sandsynligvis ikke.
>
> > 4) Muligheden for at transmitere ikke 8 bit word data [f.eks 9 bit].
>
> Dette er heller ikke et problem i den virkelige verden.
Det er et spørgsmål om hvordan du definerer den "virkelige" verden.
>
> > 5) Muligheden for at stoppe en transmission - uden at vente på at IP
> > skal fejlhåndtere.
>
> øhh... luk for tcp forbindelsen? Det virker da fint... Hvis det er
> pga. af en server der er gået død, så skal du da vente ligeså meget i
> ftp, da klienten vil vente på timeout...
Faktisk har du på ftp flere muligheder, end bare at vente på timeout, du
har trods alt 2 kanaler.
>
> 5b) Mulighed for at stoppe overførelse af en fil og samtidig
> forblive forbundet.
>
> Nej desværre... HTTP har ikke denne mulighed. Men på den anden side
> kan mange FTP klienter/servere ikke håndtere det ordenligt og går
> kolde.
Mest klienterne vist - og vi kan godt blive enige om at visse servere, er
langsomme om at håndtere dette.
>
> 5c) Mulighed for overførelse af flere filer på en gang.
>
> Desværre heller ikke muligt. Men oftest ikke et problem. Det er lidt
> irriterende når man arbejder med servere, der er lidt for mange der vil
> ind på.
Og hvorfor skulle det ikke være muligt - det er din klient der begrænser
det, ikke serveren.
>
> > 6) Håndtering af fejl som ikke fanges på TCP niveau. f.eks. ved system
> > fejl - fortsæt ved block N - eller gentransmitter data fra block M.
>
> Praktisk talt alle fil-retransmissioner programmer roller et par kb
> tilbage, da der ofte er fejl i de sidste par blokke inden forbindelsen
> ryger. Både FTP og HTTP tillader at man får et specifik segment af en
> fil igen.
HTTP tillader dig ikke at genhente - uden at du genstarter.
>
> > 7) Muligheden for at medsende data om filer som er påkrævet af nogle
> > systemer [ikke unix orienterede filsystemer]. F.eks til Mainframes
> > hvor det er nødvendigt at medsende record beskrivelse.
>
> Der er mulighed for at sende diverse headere via HTTP.
Ja, men her snakker vi mere data end du kan beskrive pr. standard i headere,
som Peter sagde så er muligheden i HTTP at bruge mimetypen og indpakningen.
Dog vil jeg stædigt insistere på at FTP er mere transparent her
>
> > 8) Ordentlige muligheder for bruger genkendelse og sikkerhed - Transpa-
> > rent mod filsystemet - uden ekstra opsætning af server eller klient.
>
> Sikkerhed? Du kan ikke engang få kryptering på FTP. Altså uden at
> bruge sftp eller ftp med ssl (som er ligeså meget eller mere
> ikke-standard som sftp). ssl over HTTP er derimod rimelig standard,
> men det kræver opsætning af det. HTTP servere er heller ikke normalt
> sat op til at man bruger rettighederne på filsystemet til at checke om
> brugeren har ret til at læse/skrive. På den anden side så vil en FTP
> server normalt heller ikke tillade dette da det giver for mange
> sikkerhedsproblemer. Så degenerer de begge til om serveren har
> rettigheder til at læse filen.
Jeg har _aldrig_ set en rigtig ftpserver som ikke håndterede USER,PASS(,ACCT).
Sikkerhed er mange ting - det jeg snakkede om var filsystem og fil baseret
sikkerhed - sikkerhed mod nettet er en anden side af Skagen.
>
> 9) mulighed for at gå NEMT igennem NAT og/eller firewall
>
> FTP sutter kosmisk på dette plan. Jeg har aldrig haft problemer med HTTP.
Ja, dårlige firewall opsætninger mod FTP er desværre ikke unormalt.
--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark