problema mea filosofica este ca un sethandler pentru php pus intr-un filematch de genul celui enuntat de tine mai sus apeleaza handlerul si pentru php-uri inexistente, ceea ce mi se pare aiurea, ca trece prin fastcgi doar ca sa-l scuipe la randul sau; iar configuratia pare curata, fara dude cum sunt prea ametit, sunt 2 variante: - apasul e ametit, si asa ceva nu ar trebui sa se intample ... mai sapam - doi: comportamentul e normal, files nu inseamna neaparat fisier existent asa cum stiam eu, ci pur si simplu e de fapt un regexp in location (uri); in cazul asta cum s-ar scrie corect un addtype blaphp php astfel incat gigi.php.aiurea sa nu fie executat ?
Alex 2013/10/15 Dumitru Ciobarcianu <[email protected]> > > Pasajul relevant din TFM: > > http://httpd.apache.org/docs/2.2/mod/core.html#files > > "The directives given within this section will be applied to any object > with a basename (last component of filename) matching the specified > filename." > > <Location> și <Directory> implică "path", <Files> și <FilesMatch> > implică "basename" (fișierul poate fi în orice Location sau Directory) > Pe de altă parte citimi mai departe: "Note that <Files> can be nested > inside <Directory> sections to restrict the portion of the filesystem > they apply to." > > Revenind, care este de fapt problema pe care încerci să o rezolvi ? > Sau este doar o discuție filozofică ? > > Dumitru "-Doctor, it hurts when I do that! -Then don't do it..." > > > > On 15-Oct-13 20:48 PM, Alex 'CAVE' Cernat wrote: > > eu stiam ca pentru asta ai location si locationmatch, unde nu ai nevoie > de > > fisiere pe disc > > files parca stiam ca se refera la fisiere strict existente, la fel ca > > directory > > daca nu e cum zic eu ai undeva scris negru pe alb ? ca m-am uitat prin > > documentatia de la files, dar nu zicea nici alba nici neagra (sau era > febra > > de vina) > > > > > > 2013/10/15 Dumitru Ciobarcianu <[email protected]> > > > >> > >> > >> Pentru a da posibilitatea handlerului tău să facă ce vrea cu url-ul > >> primit. Nu trebuie să existe neapărat un fișier pe disc. > >> > >> Exemplu: > >> > >> <FilesMatch \.sloboz$> > >> Set-Handler Mituc > >> </FilesMatch> > >> > >> Dacă apelez url-ul http://site.tld/persoana.sloboz > >> > >> atunci handlerul Mituc va returna un html corect prin care aruncă cu > >> sloboz în persoana. Nici un fișier necesar pe disc. > >> > >> Bun, acum, care este X-ul ? > >> > >> > >> Dumitru "the danger of C^W unix^w apache is that it lets you shoot > >> yourself in the foot" > >> > >> > >> On 15-Oct-13 20:33 PM, Alex 'CAVE' Cernat wrote: > >>> pai si atunci de ce functioneaza si pentru gigi-nu-exista.cgi ? ca nu e > >>> location, e files/filematch > >>> > >>> > >>> 2013/10/15 Dumitru Ciobarcianu <[email protected]> > >>> > >>>> > >>>> From TFM: > >>>> > >>>> http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext > >>>> > >>>> If you would prefer only the last dot-separated part of the filename > to > >>>> be mapped to a particular piece of meta-data, then do not use the Add* > >>>> directives. For example, if you wish to have the file foo.html.cgi > >>>> processed as a CGI script, but not the file bar.cgi.html, then instead > >>>> of using AddHandler cgi-script .cgi, use > >>>> > >>>> Configure handler based on final extension only > >>>> > >>>> <FilesMatch \.cgi$> > >>>> SetHandler cgi-script > >>>> </FilesMatch> > >>>> > >>>> > >>>> Dumitru > >>>> > >>>> > >>>> On 15-Oct-13 20:13 PM, Alex 'CAVE' Cernat wrote: > >>>>> salutare > >>>>> > >>>>> 2 minunate chestii legate de apache (2.2 in cazul asta) > >>>>> > >>>>> - "it's not a bug, is a feature": pe marea majoritate e sistemelor > >> (n-am > >>>>> vazut pana acum decat unul sa mearga cum trebuie, si cred ca facea > ceva > >>>>> gresit), un addhandler x-gigi-php php face executia posibila nu numai > >> la > >>>>> gigi.php, ci si la gigi.php.lupa sau ce vreti voi (spre exemplu la > >> .txt e > >>>>> 50-50 sansa, dupa care handler castiga in configuratie); si asta > pentru > >>>> ca > >>>>> in intelepciunea lor, indienii (nu aia din india) considera ca > >> extensie e > >>>>> orice vine dupa punct de oricate ori > >>>>> testat mod_php, fcgi, php-fpm (fcgi-ul e destul de destept sa-i dea > cu > >>>> 500 > >>>>> in cap la apache, nu mai stiu la fpm cum era, cert este ca cererea > >>>> ajungea > >>>>> la el ... si de fapt sarea si el la gatul indianului, ca are niste > >>>> limitari > >>>>> de extensii) > >>>>> lauda cineva redhat/centos ca are by default setari care opresc > >>>>> comportamentul de mai sus; a testat Wolfy (danke schon), ca el e fan > >>>>> centos, a trecut ca prin branza lu berbecali > >>>>> > >>>>> bun, exista solutie pentru asa braindamaged, un sethandler dupa > >>>>> files/filesmatch; eu din cate stiu astea cu files se bazeaza pe > fisiere > >>>>> care exista pe disc, cert insa este ca un /nu-exista.php (care nu > >> exista) > >>>>> ajunge si el bine mersi tot in ograda php-ului, desi in mod normal ar > >>>>> trebui sa-l scuipe apacheul cu 404, nu sa ajunga in handler de php > (un > >>>>> fisier normal il scuipa cu 404 default, deci handler definit nu > exista, > >>>> nu > >>>>> e rewrite - desi sa mai verific odata); alte idei nu mai am > >>>>> > >>>>> eu macar inteleg ca m-a underclock-at raceala, dar chiar si asa, > parca > >> e > >>>>> prea aberant ce se intampla mai sus ... any hint-uri ? > >>>>> > >>>>> danke > >>>>> Alex > >>>>> _______________________________________________ > >>>>> RLUG mailing list > >>>>> [email protected] > >>>>> http://lists.lug.ro/mailman/listinfo/rlug > >>>>> > >>>> > >>>> _______________________________________________ > >>>> RLUG mailing list > >>>> [email protected] > >>>> http://lists.lug.ro/mailman/listinfo/rlug > >>>> > >>> _______________________________________________ > >>> RLUG mailing list > >>> [email protected] > >>> http://lists.lug.ro/mailman/listinfo/rlug > >>> > >> > >> _______________________________________________ > >> RLUG mailing list > >> [email protected] > >> http://lists.lug.ro/mailman/listinfo/rlug > >> > > _______________________________________________ > > RLUG mailing list > > [email protected] > > http://lists.lug.ro/mailman/listinfo/rlug > > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
