public abstract class HttpHelpers
extends java.lang.Object
This class is for internal use only and should not be documented in the SDK API. It is not supported for any use outside of the LaunchDarkly SDKs, and is subject to change without notice.
Modifier and Type | Method and Description |
---|---|
static java.net.URI |
addQueryParam(java.net.URI uri,
java.lang.String name,
java.lang.String value)
Adds the query param to the URI.
|
static java.net.URI |
concatenateUriPath(java.net.URI uri,
java.lang.String path)
Safely concatenates a path, ensuring that there is exactly one slash between segments.
|
static boolean |
isAsciiHeaderValue(java.lang.String value)
Tests whether a string contains only characters that are safe to use in an HTTP header value.
|
public static java.net.URI concatenateUriPath(java.net.URI uri, java.lang.String path)
uri
- the URIpath
- the path to addpublic static java.net.URI addQueryParam(java.net.URI uri, java.lang.String name, java.lang.String value)
uri
- the URIname
- the name of the parametervalue
- the value of the parameterpublic static boolean isAsciiHeaderValue(java.lang.String value)
This is specifically testing whether the string would be considered a valid HTTP header value by the OkHttp client. The actual HTTP spec does not prohibit characters 127 and higher; OkHttp's check is overly strict, as was pointed out in https://github.com/square/okhttp/issues/2016. But all OkHttp 3.x and 4.x versions so far have continued to enforce that check. Control characters other than a tab are always illegal. The value we're mainly concerned with is the SDK key (Authorization header). If an SDK key accidentally has (for instance) a newline added to it, we don't want to end up having OkHttp throw an exception mentioning the value, which might get logged (https://github.com/square/okhttp/issues/6738).
value
- a string