3

Haproxy doc prefers using path_beg over url_beg to match path in urls.

As per 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.

Seems that in above case url_beg wont work, I didn't understand what does it mean. Can I have curl send full url as is which will not be matched by url_beg but path_beg will match it?

Deepak Deore
  • 691
  • 1
  • 9
  • 16

1 Answers1

3

You need to prepare haproxy for some non-standard requests too. Take a look at this weird 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/
...

For comparison, the standard way:

$ 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/
...

And how to produce the same weird GET with 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/
kubanczyk
  • 13,812
  • 5
  • 41
  • 55