Envoy's fault filter supports abort faults. When Envoy inject an abort fault it returns a response that uses text/plain as its content-type and sets "fault filter abort" as its body.

At Lyft, mobile clients try to deserialize every response that they get from the server (or/and Envoy). There are a few known issue when it comes to deserializing responses that are sent by Envoy's fault filter when an abort fault is injected:

• Even though Lyft mobile applications set application/json or/and application/x-protobuf as the value of accept header that they send as part of network requests that they make, Envoy filter returns a response with content-type equal to text/plain.
• There is no easy way to tell when Envoy injected a fault - a mobile client would need to look for "fault filter abort" body of a request in order to be sure that Envoy injected a fault but hard-coding a string like this on the client is not preferable. Can a client just assume that every request with x-envoy-fault-abort-request HTTP header set ends up getting an abort fault in response? No, it's not that simple because of the existence of x-envoy-fault-abort-request-percentage HTTP header. If a client sends a request with x-envoy-fault-abort-request HTTP header equal to 503 and x-envoy-fault-abort-request-percentage equal to 10 (10%) it's up to the Envoy to decide whether a fault should be injected or not (with 10% chance of the fault being injected).

Because of the aforementioned issues with the current Envoy's fault filter responses the following changes to fault filter's responses is proposed:

• Make fault filter return an empty response if an abort fault is injected.
• Make fault filter set the value of x-envoy-injected-faults HTTP header to abort every time an it injects an abort fault.