Должен ли я использовать .pl или .cgi для файлов веб-скриптов Perl?

Question

HI. Я создал два файла 'hello.pl' и 'hello.cgi' с кодом ниже.

#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "hello world";

Я могу просматривать страницу через оба http://www.mydomain.com/cgi-bin/hello.pl и http://www.mydomain.com/cgi-bin/hello.cgi. Какой из них больше подходит для Perl Web Dev?

Кстати, каталог 'cgi-bin', созданный моим VPS-сервером. Нужен ли мне контакт со службой поддержки VPS, чтобы удалить его или просто оставить его как этот стиль URL? Может быть, http://www.mydomain.com/perDev/hello.cgi лучше?

Answer 1

Не имеет значения, какое расширение вы используете. Вы можете настроить свой сервер так, чтобы он воспринимал .potato как файл CGI, если вам нравится.

Мое личное предпочтение было бы использовать .cgi или вообще без расширения, если это будет работать. Основной причиной этого является то, что вы предоставляете немного меньше информации всем, кто захочет атаковать ваш сценарий. Это незначительная вещь - не полагайтесь на это в качестве меры безопасности. Это мера предосторожности для куриного супа (это не повредит).

Выгода от использования .pl настолько мала, что вы можете решить использовать .pl для простого факта, что он короче, и это все равно будет достаточно веской причиной, насколько я понимаю.

Делай все, что угодно.

Answer 2

Если это вообще возможно, старайтесь не использовать расширения или даже показывать реальные имена файлов, если можете. Это можно сделать с помощью правил apache mod_rewrite или системы диспетчеризации с вашей платформой ( Dancer , CGI :: Application , Catalyst и т. Д.).

Некоторые делают это, потому что это немного запутывает вещи и может обеспечить немного дополнительной безопасности (но не так много, если таковые имеются). Но я делаю это, потому что это не привязывает вас к конкретной реализации. То, что начинается с некоторых простых сценариев, может превратиться в полноценное приложение, и люди будут раздражены, если вы лишите законной силы их закладки. Поэтому, выбирая что-то абстрактное, вы получаете больше свободы делать то, что вы хотите в будущем.

Answer 3

Мои обычно называются .fcgi (я использую FastCGI, а не обычный CGI), но пользователь никогда не видит имя программы благодаря небольшому переписыванию URL в .htaccess. Для пользователей гораздо приятнее иметь возможность просто перейти на http://mysite.com/ вместо http://mysite.com/mycode.fcgi, в конце концов.

Функционально он идентичен независимо от расширения. Как сказал daotoad, сервер может быть настроен на распознавание того, что что-то является исполняемым файлом CGI на основе любого расширения файла, которое вы выбираете, или по его расположению в файловой системе (сайты, использующие каталог / cgi-bin /, обычно обрабатывают все в этом каталоге в качестве программы CGI независимо от имени или расширения) или даже файлов с индивидуальными именами без видимого шаблона или связи между ними.

Answer 4

Использование нет .

Поскольку URL-адреса должны быть значимыми и независимыми от технологий .

Современные веб-фреймворки Perl, такие как Dancer или Mojolicious , могут помочь вам достичь этого.

Answer 5

Не используйте расширение или что-то общее, например .cgi.

daotoad верен в том, что .pl является незначительной утечкой безопасности, но что более важно, он привязывает ваши URL к вашему текущему языку реализации.URL-адреса должны быть постоянным местом для информации.Если в будущем вы решите переписать ваше приложение на другом языке, вы застрянете с устаревшим расширением .pl.

То же самое относится и к программам командной строки.Просто напишите command, а не command.pl, и пусть строка #! сделает свою работу.В конце концов, мы не запускаем ls.c.

mpeters, это также правильно, так как вам следует избегать привязки ваших URL-адресов к реальным файлам, опять же не столько в целях безопасности, сколько для того, чтобы сделать URL-адрес постоянным интерфейсом.Например, вы хотите http://example.com/login, а не http://example.com/cgi-bin/login.

Answer 6

При прочих равных условиях я бы назвал его .cgi, чтобы напомнить кодировщику, что это не просто еще один сценарий Perl и имеет особые требования к надежности для CGI.