Handle Blank response (RESPONSE CODE 204) in the Prebid Mobile SDK

[avohraa]

Describe the bug

• Prebid Mobile SDK was only handling HTTP response codes, 200 and 400. We have made the change to indicate response code 204 as a no-bid. It looks like nobody has raised this an issue, but given that it is confusing, we feel confident that the prebid community will review and merge our PR for this.

[YuriyVelichkoPI]

Prebid SDK supports the Prebid server endpoints and specification of the bid response https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#sample-response

Which doesn't contain an option with 204.

In general, it makes sense so I'm ok with such changes.

My question is how urgent this request is?

cc: @mittal-ank @mmullin

[srijithnair]

@YuriyVelichkoPI - thanks. This is not an urgent request and can be included in the next scheduled release. This is referenced in the OpenRTB 2.5 spec (4.2.1 Object: BidResponse), as a possible response code. Right now, the SDK treats 204 responses as "PREBID_SERVER_ERROR", which is misleading and causes confusion.

[YuriyVelichkoPI]

@bretg how do you think, is it make sense to treat 204 as "no bids" for PBS? From the client's perspective, I'm not totally sure about it because if the server (Prebid Server in this case) responds with the status that is not listed in the available statuses the client (Prebid SDK in this case) can treat such unexpected status as an error. So in this case there is a difference in the RTB and PBS specs and it would be great to make it consistent and out all players to the same page.

[mansinahar]

@YuriyVelichkoPI @avohraa @srijithnair In case of no bids, Prebid Server still responds with a 200 response and not a 204 response. This was discussed a couple months back in the Prebid.org committee meeting as well and one of the reasons 204 doesn't exactly work for a no bids response is because even when there are no bids to return, Prebid Server still might need to send debug data in the response. You can see a brief summary of that discussion in this thread.

I am happy to bring this up again in the next committee meeting but for now, can you please provide more context around what is the use case for this?

[YuriyVelichkoPI]

As I understand these changes are dedicated to the custom header bidding server. It is not the first time when @srijithnair @avohraa make such requests for the SDK. The first time we added the custom behaviour via custom SDK settings. Maybe we should act here in the same way. Because 204, for now, is not in the list of PBS statuses so should be treated by the PBS client like an error. Unless another option is set by the publisher.

@mansinahar @bretg, what do you think about it?

@mittal-ank we should determine which servers the SDK supports. It can be only Prebid Server, or Prebid Server + Prebid forks, or even any ad server. In the case of the second or the third option, we should think about pluginable and modular SDK architecture when publisher can select or provide components for the custom services (not only the server but also for example targeting).

[bretg]

I don't view this as a Prebid Server question. Agree with Mansi that PBS doesn't utilize HTTP 204. Whether the SDK and/or PBJS want to support other servers is up to those teams.

My recommendation would be to support easy and safe wins that support interoperability with creative use cases. This sounds easy and safe to me.

[YuriyVelichkoPI]

Hi @avohraa!

Last question here :)

Could you implement the same for iOS?

[avohraa]

@YuriyVelichkoPI Yes, we will be implementing the same in iOS as well.