Назад | Перейти на главную страницу

разница между url_beg и path_beg в haproxy

Документ Haproxy предпочитает использовать path_beg вместо url_beg для соответствия пути в URL-адресах.

Согласно https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#url:

With ACLs, using "path" is preferred over using "url", because clients may send a full URL as is normally done with proxies.

Похоже, что в приведенном выше случае url_beg не работает, я не понял, что это значит. Могу ли я сделать так, чтобы curl отправлял полный URL-адрес как есть, который не будет соответствовать url_beg но path_beg будет соответствовать этому?

Также нужно подготовить haproxy для некоторых нестандартных запросов. Взгляните на это странное GET:

$ echo -ne "GET http://google.com/books/ HTTP/1.1\r\nHost: google.com\r\n\r\n" | nc -v google.com 80
Connection to google.com 80 port [tcp/http] succeeded!
HTTP/1.1 301 Moved Permanently
Location: http://books.google.com/books/
...

Для сравнения стандартный способ:

$ echo -ne "GET /books/ HTTP/1.1\r\nHost: google.com\r\n\r\n" | nc -v google.com 80
Connection to google.com 80 port [tcp/http] succeeded!
HTTP/1.1 301 Moved Permanently
Location: http://books.google.com/books/
...

И как произвести такой же странный GET с curl:

$ curl -v --request-target http://google.com/books/ http://google.com/books/
*   Trying 172.217.16.14...
* TCP_NODELAY set
* Connected to google.com (172.217.16.14) port 80 (#0)
> GET http://google.com/books/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.55.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Location: http://books.google.com/books/