I don't mind having the new API because it corresponds to the existing setter API.
However, both APIs don't look very nice to me because the use case is limited to handling very small objects. What if the object I'm trying to get is video content? Does it allocate a big buffer for it? I don't think we should assume a response body is an HTML file. The setter API does not suit this kind of use case below. https://blog.sentry.io/fallbacks-for-http-404-images-in-html-and-javascript/#providing-image-fallback-urls-from-the-server - Masakazu On Thu, Mar 14, 2024 at 3:09 PM Leif Hedstrom <zw...@apache.org> wrote: > We have an existing API to set the error body (TSHttpTxnErrorBodyGet() ), > and I’d like to add the corresponding Get’er for this. I’m proposing the > following: > > /** > Retrives the error body, if any, from a transaction. This would be a > body as set > via the API body. > > @param txnp HTTP transaction whose parent proxy to get. > @param buflength Optional output pointer to the length of the body > message. > @param mimetype Optional output pointer to the MIME type of the > response. > */ > char *TSHttpTxnErrorBodyGet(TSHttpTxn txnp, size_t *buflength, char > **mimetype); > > > > The buflength and mimetype are pointers (output), which can be nullptr’s. > If they are provided, the length and/or mimetype pointer as set using the > TSHttpTxnErrorBodyGet() is also returned. The return value is the body > string. > > > This new API would return a nullptr if no error body has been set via the > TSHttpTxnErrorBodySet() API. > > Cheers, > > — Leif > > Thanks to Jasmine Emanuoel for some great ideas around how to use these > APIs together with HTTP Txn errors. > >
