diff options
| author | Murilo Ijanc <[email protected]> | 2026-07-27 20:38:46 -0300 |
|---|---|---|
| committer | Murilo Ijanc <[email protected]> | 2026-07-27 20:38:46 -0300 |
| commit | 3506a69f15fdf1c1c80acec26e906e6f25eeff14 (patch) | |
| tree | 626ddce348a635e91aa7a5d3f64f39e2ba374841 /test/http_server.c | |
| parent | ef1e5586a47002a6f21f43871b5fcfdb2c60af5d (diff) | |
| download | fortran-99db9fe733142f872bba3a7c358d5b593f9c18f0.tar.gz | |
A CEP that fails is rarely a random number. It is usually someone who
knows the city and guessed the digits, and the classic guess is the -000
that 957 municipalities never received. Answering that with a bare "not
found" throws away what the API already knows: which municipality the
number would have fallen under.
The 404 now carries an optional faixa, and it is exposed the way geo
already is — a derived type behind a logical flag on the address, because
the API omits the block entirely rather than sending null. It stays a
404: found is still false and the status is still CEPIS_ERR_NOT_FOUND.
The band is context for the failure, never an address.
cep_ini and cep_fim are the smallest and largest CEP that actually exist
there, not the bounds the Correios publish — the published start for
Areal is 25845000, exactly the CEP that fails. The pair is not a list
either: 118 CEPs over some 4,900 numbers, which is what ceps is for.
Parsing is deliberately silent about every failure. A body that is not
JSON, or a faixa that is absent, null, not an object or empty, leaves
has_faixa false. Turning any of those into an invalid-response error
would tell the caller to retry a CEP that will never exist.
Diffstat (limited to 'test/http_server.c')
0 files changed, 0 insertions, 0 deletions