Should PBFs return 404s?

[ramunasd]

Usually zero length response with status 200 and application/x-protobuf is returned in other services when vector tile is completely empty. Tessera returns 404 without any headers.

[mojodna]

This is intentional (mainly because returning 404s instead of empty images bypasses the need for browsers to parse the files). Is it causing problems for you?

[ramunasd]

Hi @mojodna , i totally agree with You regarding raster images. They are shown directly by browser and 404 responses is handled well.

Vector tiles is totally another story. Whole parsing and displaying is done by javascript libraries. That's why is crucial to have correct response code.

And yes, we are facing some problems. Currently mapbox gl js is throws error after each 404 response.

[tsemerad]

Are we sure this check is necessary? I'm using Mapbox GL JS 0.31.0, and when I request a non-existent tile it throws Error: http status 200 returned without content. If I change tessera to return a 404, Mapbox GL JS throws Error: Not Found. Is there any benefit to throwing one error over the other?

For my use case, I need it to return a 404. If it returns a 200 with no data, the Mapbox GL map thinks it got the tile it needs so it won't re-request that tile when panning back over the tile's location later in the map's lifecycle. Since my tile source is pulling tiles from a separate tile server that it can't always connect to, this leaves my map with occasional empty tiles that aren't resolved when the tile source regains internet connection. But if tessera returns 404s, the map recovers elegantly.

For now I'll be using a fork of tessera that returns a 404. Are you opening to reverting this behavior? At least for @ramunasd's original concern, it looks like it is now throwing an error regardless of 404 or 200.

[mojodna]

A 200 with no data is more likely to be cached by CDNs (etc., seemingly including Mapbox GL's tile loader) with some sort of default TTL. It also suggests to clients that a body may be present (to be dealt with some way, exactly as you note).

I would rather return 404s (particularly to be consistent between formats being served) but haven't had enough experience in practice to know which way is better. Thus, I would totally be open to reverting this behavior.

@tsemerad @ramunasd can you confirm that recent versions of Mapbox GL gracefully handle 404s? If so, I'll revert 46819a7.

[ramunasd]

I've tested this issue with recent mapbox gl versions and looks like there was improvement on how it handles 404 responses.
As for me, we can revert this change.

[tsemerad]

I can confirm that Mapbox GL version 0.31.0 is handling 404s gracefully.

[mojodna]

Published in v0.10.0.