Please clarify Reality target server requirements

[nihil-admirari]

From https://github.com/XTLS/REALITY/blob/main/README.en.md:

For general proxy purposes, the minimum standard of the target website: Websites out of China's GFW, support TLSv1.3 and H2, the domain name is not used for redirection (the main domain name may be used to redirect to www) Bonus points: target website IP reside closer to proxy IP (looks more reasonable, and lower latency), handshake messages after Server Hello are encrypted together (such as dl.google.com), OCSP Stapling Configuration bonus items: Block the proxy traffic back to China, TCP/80, UDP/443 are also forwarded to target (REALITY behaves like port forwarding to the observer, the target IP may be better if it is an uncommon choice among REALITY users)

I have two question:

1. What forms of redirections are OK? Redirecting to www is said to be fine. https://apps.microsoft.com redirects to https://apps.microsoft.com/?hl=en-US&gl=en. Is it fine to use a target that changes query parameters or the path?

2. I haven't found anything about ‘messages after ServerHello being encrypted together’ in a description of TLS handshake. I did find the following question on Stackoverflow:

   Everything seems pretty normal to me except line 61 which is encrypted. … I have absolutely no understanding how message line 61 can be encrypted since I do not understand how client and server could have exchanged sufficient data to encrypt anything so soon.

   The answer is https://stackoverflow.com/a/29043563:

   After deep investigation, it actually looks like there is no real Encrypted Handshake Message: wireshark fails to regroup handshake records when they're split. The Encrypted Handshake Message is actually an artifact due to this problem.

   Since record max length is 2^14 bytes, whenever a handshake message is longer, it is split over multiple records.

   Wireshark as well as my "failing client" seem to fail reconstructing these split records. Looks like a known unfixed bug in wireshak: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303

   Does handshake messages after Server Hello are encrypted together (such as dl.google.com) simply refer to the above mentioned Wireshark bug? If not, can anyone provide a link to the specification describing such a behaviour, and a way to check whether the server supports it? TLS 1.3, HTTP/2 and OCSP stapling can be checked with

   curl --tlsv1.3 --http2 --cert-status https://apps.microsoft.com