Onderwerp: 501 Protocol scheme 'file' is not supported

Deze melding krijg ik met een Perl-script. Googelen helpt mij niet veel
verder, net zo min als www.perl.org.

Wat kan ik doen ?

Groet,

Joachim

Joachim Smit <joachim@onzin.abc> wrote:
> Deze melding krijg ik met een Perl-script. Googelen helpt mij niet veel
> verder, net zo min als www.perl.org.
>
> Wat kan ik doen ?

Meer informatie geven!

Iets krijgt een URI aangeboden in de vorm van file://pad/naar/file en is
zo vriendelijk om te melden dat dit scheme niet onderstuend wordt.

--

Daniel Tryba

> Meer informatie geven!
>
> Iets krijgt een URI aangeboden in de vorm van file://pad/naar/file en is
> zo vriendelijk om te melden dat dit scheme niet onderstuend wordt.

Ik begrijp die hele melding niet. Als database-programmeur weet ik wel wat
een 'schema' is, maar van een 'scheme' heb ik nog nooit gehoord. Google
leert mij dat het een programmeertaal is ?? In ieder geval hielp het mij
niet veel verder. Mijn boekje "Perl in 24 hours" ook niet ;-)

In het foutlog staat helemaal niets bijzonders, ik heb geen idee waar die
melding vandaan komt.

Het enige wat ik kan doen is het access_log bekijken op de server waar het
wel draait en dat vergelijken met het access_log op de server waar hij het
niet doet, en dan naar de verschillen kijken.

We zien dan dat de laatste regel van SERVER WEL niet staat bij SERVER NIET.
Ik mag er dus vanuit gaan dat daar het probleem zit. Kan het zitten in
lwp-request/2.01 ?

Groet,

Joachim


=== BEGIN SERVER WEL

10.0.0.5 - - [23/Apr/2004:08:10:03 +0200] "GET
/cgi-bin/progress.cgi?iTotal=155812&iRead=0&iStatus=0&sessi onid=635105a5089f
ab9da8d5978d6df4314a&dtnow=1082700601&dtstart=1082 700601 HTTP/1.1" 200 855
"http://10.0.0.2/klanten/pgbar.php?iTotal=-1&iRead=0&iStatus=1&sessionid=635
105a5089fab9da8d5978d6df4314a" "Mozilla/4.0 (compatible; MSIE 6.0; Windows
NT 5.1)"
10.0.0.2 - - [23/Apr/2004:08:10:05 +0200] "POST
/klanten/upload2.php?sessie=635105a5089fab9da8d5978d6df4314 a HTTP/1.1" 200
584 "-" "lwp-request/2.01"

=== EIND SERVER WEL

===BEGIN SERVER NIET

217.136.51.88 - - [23/Apr/2004:07:59:10 +0200] "POST
/cgi-bin/upload.cgi?sid=19a60417d55015f94c8fcd94c138e950 HTTP/1.1" 200 408
217.136.51.88 - - [23/Apr/2004:07:59:27 +0200] "GET
/cgi-bin/progress.cgi?iTotal=155815&iRead=94116&iStatus=0&s essionid=19a60417
d55015f94c8fcd94c138e950&dtnow=1082699958&dtstart= 1082699950 HTTP/1.1" 200
701
217.136.51.88 - - [23/Apr/2004:07:59:38 +0200] "GET / HTTP/1.1" 304 -

=== EIND SERVER NIET

> We zien dan dat de laatste regel van SERVER WEL niet staat bij SERVER
NIET.
> Ik mag er dus vanuit gaan dat daar het probleem zit. Kan het zitten in
> lwp-request/2.01 ?

Wellicht dat LWP niet correct geinstalleerd is. LWP heb ik verwijderd en met
behulp van MCPAN geprobeerd opnieuw te installeren. Helaas komt hij niet
door de test.

Hieronder staat het foutrapport. Wat nu ?

Groet,

Joachim

Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
---
html/form-param.t 2 512 24 48 200.00% 1-24
html/form.t 2 512 52 104 200.00% 1-52
live/validator.t 2 512 2 4 200.00% 1-2
1 test skipped.
Failed 3/41 test scripts, 92.68% okay. 78/687 subtests failed, 88.65% okay.
make: *** [test] Error 2
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force

cpan>

Joachim Smit <joachim@onzin.abc>:
>> We zien dan dat de laatste regel van SERVER WEL niet staat bij SERVER
>> NIET. Ik mag er dus vanuit gaan dat daar het probleem zit. Kan het
>> zitten in lwp-request/2.01 ?
>
> Wellicht dat LWP niet correct geinstalleerd is. LWP heb ik verwijderd en
> met behulp van MCPAN geprobeerd opnieuw te installeren. Helaas komt hij
> niet door de test.
>
> Hieronder staat het foutrapport. Wat nu ?

De kans nemen en 'force install LWP' doen? Bij 92% goede tests is dat mijn
standaard oplossing

--
robert

> De kans nemen en 'force install LWP' doen? Bij 92% goede tests is dat mijn
> standaard oplossing

Heb ik gedaan maar de fout bleef.

Vervolgens heb ik HTML:Tagset en HTML:Parser verwijderd en opnieuw
geinstalleerd. Vervolgens kon ik LWP wel keurig installeren. De foutmelding
"501 Protocol scheme 'file' is not supported " blijft echter bestaan.

Ai, ai, ai, wat bezorgt me dit toch een hoofdbrekens.

Groet,

Joachim

> Waarom krijg ik dan nog steeds deze melding : "501 Protocol scheme 'file'
is
> not supported "

Is er niet een manier om precies te zien op welke regel hij eruit springt?
Een manier om stap voor stap te zien wat-ie doet ?

Groet,

Joachim

> Is er niet een manier om precies te zien op welke regel hij eruit springt?
> Een manier om stap voor stap te zien wat-ie doet ?


Dit is de boosdoener:

==BEGIN

print " Dit gaat goed " ;

open (POST,"|$post_prog -c\"$content_type\" $php_uploader?sessie=$sessionid
");

==EIND

Als de variabele $php_uploader de waarde '/klanten/upload2.php' heeft dan
komt de melding 501 "Protocol scheme 'file' is not supported " en als hij de
waarde heeft 'http://123.456.789.123/klanten/upload2.php' dan komt de
melding "Protocol scheme 'http' is not supported".

In beide gevallen wordt het zinnetje "Dit gaat goed" nog wel afgebeeld.

Ik weet het echt niet meer.

Groet,

Joachim

Joachim Smit <joachim@onzin.abc>:
>> Is er niet een manier om precies te zien op welke regel hij eruit springt?
>> Een manier om stap voor stap te zien wat-ie doet ?
>
> Dit is de boosdoener:
>
>==BEGIN
>
> print " Dit gaat goed " ;
>
> open (POST,"|$post_prog -c\"$content_type\" $php_uploader?sessie=$sessionid
> ");

Ben je er 100% zeker van dat bovenstaande variabelen geheel en al
veilig zijn (dus niet door externen, bv als formulierelement, worden
doorgegeven)? Anders is je code ontvankelijk voor code-injectie.

>==EIND
>
> Als de variabele $php_uploader de waarde '/klanten/upload2.php' heeft
> dan komt de melding 501 "Protocol scheme 'file' is not supported "...

Ik ga ervan uit dat $post_prog een geldige HTTP URL nodig heeft, en
'/klanten/upload2.php' is dat niet. Het programma zal zien dat je geen
scheme (niet de programmeertaal, maar in feite de beschrijving van de
accessmethode van de url; voorbeelden zijn 'file', 'http', 'ftp', enz)
opgeeft, en neemt 'file' als default.

> ...en als hij de waarde heeft
> 'http://123.456.789.123/klanten/upload2.php' dan komt de melding
> "Protocol scheme 'http' is not supported".

Wat is $post_prog precies, en kan je die wel vanaf de commandline
gebruiken?

--
robert

> Ben je er 100% zeker van dat bovenstaande variabelen geheel en al
> veilig zijn (dus niet door externen, bv als formulierelement, worden
> doorgegeven)? Anders is je code ontvankelijk voor code-injectie.

Ja. De scripts zijn op geen enkele manier gekoppeld aan formulier-elementen.
>
> Ik ga ervan uit dat $post_prog een geldige HTTP URL nodig heeft, en
> '/klanten/upload2.php' is dat niet. Het programma zal zien dat je geen
> scheme (niet de programmeertaal, maar in feite de beschrijving van de
> accessmethode van de url; voorbeelden zijn 'file', 'http', 'ftp', enz)
> opgeeft, en neemt 'file' als default.
>

> Wat is $post_prog precies, en kan je die wel vanaf de commandline
> gebruiken?


$post_prog heeft altijd de waarde '/usr/bin/POST'

Voordat ik ging installeren heb ik natuurlijk de README gelezen. Daarin
staat welke Perl-modules geinstalleerd moeten zijn. Zoals ik in een andere
posting al schreef, onder RH9 werkte het direct. Het gaat nu om een
Trustix-distro en dat is dus een drama.

Ik heb op de site gekeken voor eventuele extra support van degene die de
scripts geschreven heeft.

http://www.raditha.com/php/checklist.php

En wat blijkt ? Nu wordt ook de module Cookie uit de hoge hoed getoverd. Ik
neem aan dat ze met de module Cookie Apache::Cookie bedoelen. Ik heb zowel
de module Apache geinstalleerd, alsook Bundle::Apache geprobeerd,
Apache::Cookie zit daar niet bij. Als ik vervolgens Apache::Cookie probeer
te installeren vraagt hij om de module mod_perl. Die kan ik niet installeren
want dat geeft een hele reeks foutmeldigen. Dat zou onder andere kunnen
komen omdat hij vraagt waar de sources van Apache staan, maar die heb ik
niet geinstalleerd. Wel de RPM met de Apache-sources gedownload, maar
'rpm -i apache-2????.src.rpm' doet helemaal niets.

Wat ongelofelijk frustrerend omdat ik weet dat als ik het op een RH of
Debian installeer ik het binnen 10 minuten aan de praat heb.Deze server
staat alleen 220 km verderop. Vandaar dat ik het zo maar even doe. Achteraf
bezien had ik in dezelfde tijd dat ik er nu mee bezig ben al 10 keer heen en
weer kunnen rijden.

Dom, dom, dom.

Groet,

Joachim

Als je een andere optie hebt om een progress-bar te installeren voor een
PHP-site waar grote ( tot 20 Mb) bestanden moeten kunnen worden ge-upload
hoor ik dat graag. Dan donder ik mega-upload overboord.

Groet,

Joachim

Joachim Smit <joachim@onzin.abc>:
>> Ben je er 100% zeker van dat bovenstaande variabelen geheel en al
>> veilig zijn (dus niet door externen, bv als formulierelement, worden
>> doorgegeven)? Anders is je code ontvankelijk voor code-injectie.
>
> Ja. De scripts zijn op geen enkele manier gekoppeld aan
> formulier-elementen.

Prima, just checking

>> Wat is $post_prog precies, en kan je die wel vanaf de commandline
>> gebruiken?
>
> $post_prog heeft altijd de waarde '/usr/bin/POST'

Kan je die vanaf de commandline draaien met de argumenten die je er vanuit
je Perl script aan op geeft? En is er een specifieke reden waarom je POST
gebruikt in plaats van dat je de functionaliteit zelf implementeert?

> Voordat ik ging installeren heb ik natuurlijk de README gelezen. Daarin
> staat welke Perl-modules geinstalleerd moeten zijn. Zoals ik in een
> andere posting al schreef, onder RH9 werkte het direct. Het gaat nu om
> een Trustix-distro en dat is dus een drama.

Balen

> En wat blijkt ? Nu wordt ook de module Cookie uit de hoge hoed
> getoverd. Ik neem aan dat ze met de module Cookie Apache::Cookie
> bedoelen.

Niet persé, als je in de CPAN shell 'i /Cookie/' uitvoert, zie je dat er
behoorlijk wat Cookie mods zijn. Ik verwacht dat ze HTTP::Cookies bedoelen,
onderdeel van LWP.

--
robert

> Kan je die vanaf de commandline draaien met de argumenten die je er vanuit
> je Perl script aan op geeft? En is er een specifieke reden waarom je POST
> gebruikt in plaats van dat je de functionaliteit zelf implementeert?

Het was een kant en klaar script, waar nauwelijks aan veranderd hoefde te
worden. Ik heb het niet zelf geschreven.

> Niet persé, als je in de CPAN shell 'i /Cookie/' uitvoert, zie je dat er
> behoorlijk wat Cookie mods zijn. Ik verwacht dat ze HTTP::Cookies
bedoelen,
> onderdeel van LWP.

Ik zit nu bijna 24 uur op kantoor, ik ga zo maar eens naar huis om te kijken
of ik nog steeds verloofd ben ;-)

Dan maar even nadenken. Misschien dat het makkelijker is om hier ter plekke
een Debian-machine helemaal klaar te maken en die van de week om te wisselen
met die klote-ding daar. Ik heb in ieder geval wel veel geleerd het
afgelopen etmaal.

En wellicht een mooie gelegenheid om weer eens een koud biertje te drinken
op het terras van het Leidseplein. Da's al jaren geleden.

Bedankt voor je hulp in ieder geval.

Vriendelijke groet,

Joachim

Joachim Smit <joachim@onzin.abc>:
>> Kan je die vanaf de commandline draaien met de argumenten die je er
>> vanuit je Perl script aan op geeft? En is er een specifieke reden
>> waarom je POST gebruikt in plaats van dat je de functionaliteit zelf
>> implementeert?
>
> Het was een kant en klaar script, waar nauwelijks aan veranderd hoefde
> te worden. Ik heb het niet zelf geschreven.

Dat weet ik, het is onderdeel van LWP Maar de functionaliteit zelf
implementeren is ook niet zo moeilijk. Het ligt er natuurlijk gewoon aan
waar je prioriteiten liggen

>> Niet persé, als je in de CPAN shell 'i /Cookie/' uitvoert, zie je dat
>> er behoorlijk wat Cookie mods zijn. Ik verwacht dat ze HTTP::Cookies
>> bedoelen, onderdeel van LWP.
>
> Ik zit nu bijna 24 uur op kantoor, ik ga zo maar eens naar huis om te
> kijken of ik nog steeds verloofd ben ;-)
>
> Dan maar even nadenken. Misschien dat het makkelijker is om hier ter
> plekke een Debian-machine helemaal klaar te maken en die van de week
> om te wisselen met die klote-ding daar. Ik heb in ieder geval wel veel
> geleerd het afgelopen etmaal.
>
> En wellicht een mooie gelegenheid om weer eens een koud biertje te
> drinken op het terras van het Leidseplein. Da's al jaren geleden.

Succes ermee

--
robert