Hi @pierrejeambrun, here is the update:

Common Accept Header for JSON and Text

I have added HeaderAcceptJsonOrText in common/headers.py, annotated with Mimetype from common/types.py.

I tested it with application/json; charset=utf-8, and for headers including utf-8, we need to use startswith to match the header correctly. Additionally, I included an OpenAPI schema for the Accept header.

Just resolve the conflict 🚀

Hello @jason810496 do you mind fixing the formatting errors, it would be great to merge this one :)

I was just testing this and noticed that we're passing all the values as strings. It would be nice if I am passing 'application/json' that values are actually converted so 'True' becomes true, '5' becomes 5

I was just testing this and noticed that we're passing all the values as strings. It would be nice if I am passing 'application/json' that values are actually converted so 'True' becomes true, '5' becomes 5

I think, that would require us to maintain a Model with all possible configs along with their type. From what I remember, we typecast them after retrieving from the config. For example, retries are fetched as a string and then typecasted in methods. Wrong example.

But, AirflowConfigParser has methods defined to typecast and reuse. Like for log_fetch_timeout

https://github.com/rawwar/airflow/blob/9f0c4dfe224fbc417eb107f04c19d7108341f839/airflow/utils/log/file_task_handler.py#L92

@bbovenzi , Should I create a separate issue? I don't think its a trivial change

I would be for creating an issue, and tagging that as a feature request ?

Unless this was already implemented in the legacy endpoint but I don't believe so.

That would be a great addition. Full string values is quite limited and force work on the client side.

I think I'll make this a feature for the UI only config endpoint