[java] url exists en isDirectory.

[Alarmnummer]

Bij een file is het eenvoudig om te achterhalen of een file een directory is of als hij bestaat. Bij een URL is het een stuk lastiger. Het bestaan van een URL kan je aantonen door een connectie er naar te openen, maar om te controleren of het een directory heb ik nog geen oplossing voor gevonden.

Wie weet hier een oplossing voor? Of wie weet nog een goeie api om het werken met URL wat handiger te maken?

[Erkens]

volgens mij kan dat niet?
want de webserver stuurt of een 403 of een file terug, welke dus een direcotry index kan zijn die gemaakt wordt door de server, of een index file (index.html/index.php etc)

[Alarmnummer]

Hmmzz.. daar zeg je me idd ook iets.

[drm]

Erkens:
volgens mij kan dat niet?
want de webserver stuurt of een 403 of een file terug, welke dus een direcotry index kan zijn die gemaakt wordt door de server, of een index file (index.html/index.php etc)

Dat is volgens mij niet 100% waar. Als je namelijk naar een URL surft die een directory is:

code:

http://www.de-url.com/directory

Komt er van de server een response, die vertelt aan de browser: "Jo, je hebt een directory te pakken", want gek genoeg verschijnt er een slash achter de url.

code:

http://www.de-url.com/directory/

Ik weet niet of dat webserver afhankelijk is, maar het zou mij niets verbazen als dat onderdeel is van HTTP. Ik heb hier helaasch ethereal niet bij de hand anders zou ik dat voor je kunnen bekijken.

[mbravenboer]

Bash:

[mbravenb@porkpie mbravenb]$ curl http://losser.st-lab.cs.uu.nl/~mbravenb/software -D headers
....
[mbravenb@porkpie mbravenb]$ more headers
HTTP/1.1 301 Moved Permanently
Date: Wed, 20 Aug 2003 12:43:16 GMT
Server: Apache/1.3.28 (Unix) PHP/4.0.3
Location: http://losser.st-lab.cs.uu.nl/~mbravenb/software/
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
 

Als je de / erachter aangeeft, krijg je direct een resultaat en is het dus lastiger te achterhalen. Ook is het natuurlijk nog maar de vraag wat andere webservers doen ...

[Alarmnummer]

Het gaat mij er in ieder geva om dat ik kan controleren of een bepaalde url bestaat, en of het wel of geen directory is. Bepaalde rulebases (redeneerbestanden) worden op basis van een url opgehaald, maar ook directories met rulebases worden mbv een url ingesteld. Ik moet dan in een soortment van fileviewer de user een bepaalde rulebase kunnen laten selecteren, of hem laten browsen in een directory.

[Erkens]

mbravenboer schreef op 20 August 2003 @ 14:44:

Als je de / erachter aangeeft, krijg je direct een resultaat en is het dus lastiger te achterhalen. Ook is het natuurlijk nog maar de vraag wat andere webservers doen ...

klopt, maar http://gathering.tweakers.net/forum krijgt geen / erachter aangezien forum een file is. (en met / kan het ook in dit geval)
dus het is heel moeilijk om te kijken of het een directory is of een bestand.

[Verwijderd]

Het doet er niet toe, de informatie die je terug krijgt is altijd een document. Directory listing in http bestaat niet...

[mbravenboer]

'Browsen' in een directory is sowieso onmogelijk. Er is geen standaard faciliteit (in HTTP oid) om de inhoud van een directory op een webserver te bekijken.

Voor de gein heb ik even deze post in nl.comp.programmeren opgezocht van jaaaaaren geleden: [java] inlezen filenames in een array

[drm]

Erkens:
klopt, maar http://gathering.tweakers.net/forum krijgt geen / erachter aangezien forum een file is. (en met / kan het ook in dit geval)
dus het is heel moeilijk om te kijken of het een directory is of een bestand.

Dat is nou precies de reden dat er juist onderscheid is.

Maar uit de headers die mbravenboer post blijkt wel dat het (waarschijnlijk) een feature Apache is. Toch zou het mij niet verbazen als Apache dit doet om de browser te verplichten een URL naar een directory ook als directory op te vragen (Ik wil de inhoud van die directory zien. Oh, dan moet je er wel een slash achter zetten)

Als dat zo is, doet Apache dat vast met een reden, en zou het me nog minder verbazen dat er van een URL verwacht wordt dat er een slash achter staat als het om een directory gaat. Als dat zo is, is het een onderdeel van de HTTP specificatie, en kun je van een webserver verwachten dat hij een fout (oid) geeft als je om een bestand vraagt met een slash erachter en als je om een directory vraag zonder slash erachter.

Of is dat lulkoek? Ik heb alleen niet zo veel zin dit verhaal te verifieren, dus dat mag iemand anders doen

[mbravenboer]

Ik denk (hoop) dat HTTP weinig zegt over het mappen van URLs naar het lokale file systeem.

De webserver beslist welke resource representatie er moet worden opgeleverd voor een bepaalde URL. Als hij behulpzaam wil zijn bij het vinden van de goede URL zal hij de goede presentatie wellicht direct opleveren, of hij zal forwarden naar de goede URL. Ik kan me zelfs voorstellen dat er een forward wordt gestuurd naar een index.html ....

[Verwijderd]

drm:
Het zou het voor een browser kunnen impliceren dat een slash een directory is, maar probeer maar is een dir listing te versturen over http, dat gaat niet. Hat zal altijd 1 document blijven per request. Een oplossing zou kunnen zijn een mime-type "directory-listing" en daar dus regels aan verbinden. Maar hoe dan ook het blijft een document. Het is immers aan de webserver zelf hoe deze met de "pathInfo" omgaat.

[Soultaker]

In de specificatie zijn ze er nogal onduidelijk over.

An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed. <path> is an HTTP selector, and <searchpart> is a query
string. The <path> is optional, as is the <searchpart> and its
preceding "?". If neither <path> nor <searchpart> is present, the "/"
may also be omitted.

Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.

De "/" wordt dus gebruikt om componenten in een hierarchische structuur te scheiden, maar hoe dat dan precies moet, wordt niet aangegeven. De meer algemene omschrijving zegt:

Some URL schemes (such as the ftp, http, and file schemes) contain
names that can be considered hierarchical; the components of the
hierarchy are separated by "/".

Ik denk dus dat een URL die eindigt op een "/" geinterpreteerd moet worden als een serie componenten die eindigt met een leeg component. Als de webserver met een achterliggende directorystructuur werkt (zoals gebruikelijk is) dan worden dus gewoon de componenten als directories geinterpreteert. Het laatste component wordt dan gemapt op de naam van een bestand in de directory; is de laatste component leeg, dan wordt een default bestand genomen (index.html, of dus een gegenereerde directory index). Dat is natuurlijk redelijk implementatiespecifiek.

De URL "http://host/aap/noot" verwijst eigenlijk naar het document "noot" dat direct onder "aap" valt, terwijl de URL "http://host/aap/noot/" verwijst naar een document met een leeg identifier, die onder noot valt.

In principe mag een webserver zelf uitmaken hoe dit soort URL's geinterpreteert worden. Apache handelt beide gevallen af, maar ik kan me ook goed voorstellen dat een andere webserver ervoor kiest dat "http://host/aap/noot/" niet kan bestaan, aangezien bestanden met lege bestandsnamen onmogelijk zijn. Uiteindelijk bestaan voor de client immers uitsluitend URL's en (eventuele) bijbehorende documenten en hoe de webserver die URL's omzet naar documenten is volledig aan de webserver.

[Spider.007]

drm schreef op 20 augustus 2003 @ 14:58:
[...]
Dat is nou precies de reden dat er juist onderscheid is.

Maar uit de headers die mbravenboer post blijkt wel dat het (waarschijnlijk) een feature Apache is. Toch zou het mij niet verbazen als Apache dit doet om de browser te verplichten een URL naar een directory ook als directory op te vragen (Ik wil de inhoud van die directory zien. Oh, dan moet je er wel een slash achter zetten)

Klopt, het is inderdaad een optie van Apache om netjes een Location header te versturen naar /directory/ als je /directory opvraagt. Het uitzetten van deze optie zorgt er ook voor dat je een foutmelding krijgt dat /directory niet bestaat

Als dat zo is, doet Apache dat vast met een reden, en zou het me nog minder verbazen dat er van een URL verwacht wordt dat er een slash achter staat als het om een directory gaat. Als dat zo is, is het een onderdeel van de HTTP specificatie, en kun je van een webserver verwachten dat hij een fout (oid) geeft als je om een bestand vraagt met een slash erachter en als je om een directory vraag zonder slash erachter.

Hij doet het met de reden dat Apache zelf een slash achter de directory nodig heeft om te begrijpen dat het een directory is. Of dit onderdeel van de HTTP specificaties is weet ik ook niet...

edit:
Uit het verhaal van Soultaker blijkt dat dit ook niet duidelijk is gedefinieerd

Of is dat lulkoek? Ik heb alleen niet zo veel zin dit verhaal te verifieren, dus dat mag iemand anders doen

Soultaker schreef op 20 augustus 2003 @ 15:38:
[...]

Ik denk dus dat een URL die eindigt op een "/" geinterpreteerd moet worden als een serie componenten die eindigt met een leeg component. Als de webserver met een achterliggende directorystructuur werkt (zoals gebruikelijk is) dan worden dus gewoon de componenten als directories geinterpreteert. Het laatste component wordt dan gemapt op de naam van een bestand in de directory; is de laatste component leeg, dan wordt een default bestand genomen (index.html, of dus een gegenereerde directory index). Dat is natuurlijk redelijk implementatiespecifiek.

De URL "http://host/aap/noot" verwijst eigenlijk naar het document "noot" dat direct onder "aap" valt, terwijl de URL "http://host/aap/noot/" verwijst naar een document met een leeg identifier, die onder noot valt.

In principe mag een webserver zelf uitmaken hoe dit soort URL's geinterpreteert worden. Apache handelt beide gevallen af, maar ik kan me ook goed voorstellen dat een andere webserver ervoor kiest dat "http://host/aap/noot/" niet kan bestaan, aangezien bestanden met lege bestandsnamen onmogelijk zijn. Uiteindelijk bestaan voor de client immers uitsluitend URL's en (eventuele) bijbehorende documenten en hoe de webserver die URL's omzet naar documenten is volledig aan de webserver.

Ik denk eerder dat de webserver hier afwijkt van de standaard. Een scheidingsteken geeft duidelijk aan dat een leading of trailing teken hier niet onder valt.... Het lijkt mij dus dat de webserver hier zelf een slash erachter plakt vanwege 'common-sense' (het is immers logischer) of omdat dit in de engine wordt verwacht (wat niet geheel logisch zou zijn...)

RFC HTTP Protocol parameters
RFC Uniform Resource Locators (URL)

[ Voor 43% gewijzigd door Spider.007 op 20-08-2003 17:36 ]

[Soultaker]

Spider.007 schreef op 20 August 2003 @ 17:23:
Ik denk eerder dat de webserver hier afwijkt van de standaard. Een scheidingsteken geeft duidelijk aan dat een leading of trailing teken hier niet onder valt....

Volgens mij zegt de standaard niets over lege componenten; waarom zouden die niet mogen bestaan? Een leading/trailing seperator is dan wel degelijk een seperator, en dan zijn ook zulke constructies mogelijk: "http://host/aap//noot///mies". Wat hier het nut van is, zou ik niet weten, maar het lijkt me volgens de RFC wel een geldige URL.

[mbravenboer]

Bijna elke random string is een URI .

[Soultaker]

mbravenboer schreef op 20 August 2003 @ 18:11:
Bijna elke random string is een URI .

Maar niet elke URI is een URL!

[mbravenboer]

Maar een HTTP request betreft wel een URI .