Show either HTTP Response Header Keys or HTTP Response Headers, not both, on Log Entries

[TrangOul]

New Feature Summary

The latest release introduces a feature of logging HTTP header values together with keys (#564) in the field LogEntry__c.HttpResponseHeaders__c. For backward compatibility the old feature of logging just the keys in the field LogEntry__c.HttpResponseHeaderKeys__c is still present.

Currently both fields are present on the Log Entry FlexiPage (shown in the screenshot in #564). Since both are of long text data type, and in the case of most logged callouts they contain many lines, the page layout is quite cluttered, especially given the fact that HTTP Response Headers field contain all the information from HTTP Response Header Keys.

Would it be possible to show only one of those Log Entry fields, conditionally, depending on the flag StoreHttpResponseHeaderValues (or alternatively whether HttpResponseHeaders__c are populated)?
Since long text areas cannot be used in field visibility filter on FlexiPages, nor can custom metadata, a new technical field may be needed.

Please consider the following (LogEntryEventBuilder.cls):

final String formattedHeadersString;
(...)
this.logEntryEvent.HttpResponseHeaderKeys__c = String.join(response.getHeaderKeys(), NEW_LINE_DELIMITER);
this.logEntryEvent.AreHttpResponseHeadersLogged__c = formattedHeadersString != null;
this.logEntryEvent.HttpResponseHeaders__c = formattedHeadersString;

, then use AreHttpResponseHeadersLogged__c as a filter in LogEntryRecordPage.flexipage.

[jongpie]

@TrangOul yeah, I think this makes sense to do - for the LogEntry__c object, I already have several existing Boolean/checkbox fields to help filter on other long textarea fields, but I haven't been consistent in this for every new long textarea field. And since you can't filter on long textarea fields in SOQL, I think having checkbox fields is helpful for querying data, setting up list views, etc. Right now, I have these existing checkbox fields on LogEntry__c (which use a slightly different naming convention from your example, but the same idea):

• HasExceptionStackTrace__c - set based on logEntry.ExceptionStackTrace__c != null
• HasInlineTags__c - set based on logEntry.Tags__c != null
• HasRecordJson__c - set based on logEntry.RecordJson__c != null
• HasStackTrace__c - set based on logEntry.StackTrace__c != null

So, I'm going to create several new checkbox fields on LogEntry__c:

• HasDatabaseResultJson__c - will be set based on logEntry.DatabaseResultJson__c != null
• HasHttpRequestBody__c - will be set based on logEntry.HttpRequestBody__c != null
• HasHttpResponseBody__c - will be set based on logEntry.HttpResponseBody__c != null
• HasHttpResponseHeaderKeys__c - will be set based on logEntry.HttpResponseHeaderKeys__c != null
• HasHttpResponseHeaders__c - will be set based on logEntry.HttpResponseHeaders__c != null

That should make the data model consistent, and then I'll use HasHttpResponseHeaders__c as a filter in LogEntryRecordPage.flexipage.

[jongpie]

@TrangOul one follow-up question for you.... do you think it would be useful to sort the values in HttpResponseHeaders__c and HttpResponseHeaderKeys__c? Right now, the headers returned from response.getHeaderKeys() don't seem to be sorted in any particular way (as far as I can tell), so I was thinking of sorting the List<String>. I think that would make it easier to read/find specific keys, but let me know if you have any concerns with this idea.

[TrangOul]

@jongpie, speaking of headers order, this is what RFC 2616 RFC 7230 says:

The order in which header fields with differing field names are received is not significant. However, it is good practice to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible. A server MUST NOT apply a request to the target resource until the entire request header section is received, since later header fields might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.

A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).

A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.

As your tool is supposed just to log the original response, not to process it, I'd keep the original order.
Otherwise it'd discard the sender's "best practice" ordering, and it'd also need to use a custom sorting, which should ignore headers with the same key - IMO not worth it.

[jongpie]

@TrangOul that makes sense, I'll leave the ordering as-is. Thanks for the link/info about RFC 7230!

I've created PR #569 for this issue - it adds the new checkbox fields that I mentioned above, and adds some conditional visibility to the LogEntry__c flexipage to only show either HttpResponseHeaders__c or HttpResponseHeaderKeys__c. I'm hoping to merge this in the next day (once I complete some additional testing + writing the release notes).

[jongpie]

@TrangOul it's ready! I've just published a new release, v4.11.10 with these changes.

Thanks again for all of the feedback - let me know if you think of anything else.