Azure-sdk-for-java: Create Default Log Options for Search

[alzimmermsft]

As a convenience for request and response logging we should compile a list of log-safe headers and query parameters. These lists should be used to built a default HttpLogOptions that could be retrieved through a static getter if the user wants to mutate the default log options.

@tg-msft @bryevdv @xirzec @heaths as this will be applicable to other languages as well.

[tg-msft]

Historically we've done this by ad-hoc parsing the swagger and dumping out a list of all the unique headers/query params and then running that by the service team to figure out what we want to allow-list. We can help with that once the latest swagger is merged into azure-rest-api-specs.

[brjohnstmsft]

@tg-msft That would be a good start, but there will be headers not in the Swagger that should probably be in the allow-list, such as those related to CORS. I'll come up with a list and post it here.

[heaths]

Once we have that list, could you open bugs against all current languages? That's what I typically do for Key Vault. You can use Alex's issue creator that makes creating per-language bugs easy (only a couple things to change for each).

[brjohnstmsft]

@heaths Shared the list offline. I'm not familiar with Alex's tool. @AlexGhiondea, can you help with tracking this across languages?

[sima-zhu]

Allowed headers posted in Team channel:
Accept
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
Access-Control-Allow-Methods
Access-Control-Allow-Origin
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Request-Headers
Access-Control-Request-Method
api-key
client-request-id (I suggest we ignore this and only offer x-ms-client-request-id as an option)
Content-Type
elapsed-time
If-Match
If-None-Match
Location
OData-MaxVersion
OData-Version
Origin
Prefer
request-id
return-client-request-id (prefer x-ms-return-client-request-id over this, once it's supported in a month or so)
throttle-reason
User-Agent
x-ms-client-request-id (prefer this over client-request-id)
x-ms-return-client-request-id (not supported yet; will be in a month or so)

[tg-msft]

I'd also suggest $select as an allowed query parameter.

[alzimmermsft]

Should take 20-30 minutes to compile a full list of query parameters used by the Search service.

[tg-msft]

Just be careful because we don't want all the GET operation query params. I think $select is the only one we actually care about in a POSTing Track 2 world.

[alzimmermsft]

Appears $select is the only additional query parameter other than api-version that is used in GET operations.

[alzimmermsft]

Also, from that list it was mentioned api-key should be removed as that was a typo.

[brjohnstmsft]

We're having internal discussions around whether field names are considered "sensitive data" that might need to stay in the region of the customer's search service, so logging $select by default might be problematic for the same reason as $filter would be, at least for the query APIs (its usage for the various List APIs is innocuous).