Использование curl для запроса URL-адреса, который перенаправляет на относительный URL-адрес с тегом привязки

Я использую curl для запроса URL-адреса, который перенаправляет на другой URL-адрес с помощью Location: строка вроде:

Location:/path/to/resource#name

Насколько я понимаю, эта строка в ответе на перенаправление недействительна в соответствии со спецификациями HTTP, поэтому общий вызов curl по понятным причинам не выполняется (в данном случае с кодом ответа 400). Однако запрос URL-адреса с помощью wget или веб-браузера успешно отображает страницу (я предполагаю, что с помощью эвристики, которая заполняет абсолютный путь или удаляет тег привязки перед перенаправлением).

Могу ли я что-нибудь сделать, чтобы завиток делал то же самое (делать то, что необходимо для успешного выполнения перенаправления, даже если оно «официально» неправильно сформировано)?

Редактировать: Еще немного подробностей. Окончательный код ответа - 400 (не 404 или что-то еще). Когда я делаю запрос HEAD (с curl -I -L), Я получаю 302 Found (с участием Location: /Error), который перенаправляет на 500 Server Error. Однако, если я сделаю обычный запрос (без -I вариант, но с -L вариант), я получаю http_code (в завитках --write-out) из 400. Таким образом, похоже, что запросы HEAD в этом случае работают иначе, чем стандартные GET.

Насколько я понимаю, curl по умолчанию не следует за заголовками Location.

Вы можете включить такое поведение, используя -L или --location переключатель. Вот так:

tom@slappy:~▶ curl -I -L http://shell/redirect.php     
HTTP/1.1 302 Found
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
X-Powered-By: PHP/5.3.5-1ubuntu7.2
Location: /target.html#someAnchor
Content-Type: text/html

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Tue, 17 Jan 2012 00:10:37 GMT
Accept-Ranges: bytes
Content-Length: 7
Content-Type: text/html

Примечание: -I используется только для отображения заголовков, а не содержимого страницы. Я тестировал это с помощью curl 7.21.6, работающего в Ubuntu.

Я обнаружил, что эта конкретная проблема возникает с curl 7.15.5, но отлично работает с curl 7.21.0. Таким образом, должно быть исправление ошибки или функция, реализованная между ними, решающая ее. Если кто-то точно знает, какой патч или изменение относится к этому, мы будем признательны!