Regression: ATS 9.0.x rejects URI's with two leading /'s

[zwoop]

Albeit not technically allowed by the RFCs (as far as I can tell), this is likely a common case where clients can intentionally or accidentally send two leading /'s. All versions of ATS prior to 9.0.x handles this fine, but 9.0.x does not (since we hardened the scheme parsing algorithm).

The request would look like e.g.

GET //index.html HTTP/1.1

Which is now rejected with

[Oct  6 23:02:26.490] [ET_NET 5] DEBUG: <HttpSM.cc:773 (state_read_client_request_header)> (http) [265] error parsing client request header
[Oct  6 23:02:26.490] [ET_NET 4] DEBUG: <HttpSM.cc:658 (state_read_client_request_header)> (http) [267] [&HttpSM::state_read_client_request_header, VC_EVENT_READ_READY/TS_EVENT_VCONN_READ_READY]
[Oct  6 23:02:26.491] [ET_NET 5] DEBUG: <HttpTransact.cc:793 (BadRequest)> (http_trans) [265] [BadRequest]parser marked request bad

[bneradt]

I did a change for url parsing to address empty paths. I tried to be careful to only fix things for empty paths without breaking something else, but maybe this got through. In any case, I'd say that's also a candidate for a change that broke this:

#7119

[bneradt]

This is indeed caused by my #7119 PR. I actually explicitly added a check for this exact case and made it fail, adding a comment in the code quoting the RFC that says this should fail:

https://github.com/apache/trafficserver/blob/master/proxy/hdrs/URL.cc#L1389

  if (url->m_ptr_host == nullptr && ((end - cur) >= 2) && '/' == *cur && '/' == *(cur + 1)) {
    // RFC 3986 section-3.3:
    // If a URI does not contain an authority component, then the path cannot
    // begin with two slash characters ("//").
    return PARSE_RESULT_ERROR;
  }

Fixing this issue is simply a matter of removing that condition. I'll get a PR up shortly.