HTTP binding - missing Content-Type entry application/x-www-form-urlencoded

I’m using the http binding to get warnings for possibly icy windshields for the next morning. Dibbler42 described a great way to do this using a jython script here but I preferred to use the http binding instead.

It worked fine for some years but somehow broke a few months ago without me noticing - it was summer, then.
During the update to OH4.3 (great job, everyone!) I saw the error message from the http thing in the logs (kudos to the new log viewer, btw!) and started to investigate:

The http thing is trying to get data from a POST request to https://api.eiswarnung.de. What is “special” about this api is that they require a Content-Type header with Content-Type=application/x-www-form-urlencoded.

But this value is unavailable in the thing configuration in MainUI and cannot be set manually in the Code tab of the thing configuration, since only the pre-configured values can be used.

My previous configuration (from OH3 days) included a “Custom header” entry, which worked fine for a few years. But apparently, in OH4(.3?) an entry from the list of Content-Types is automatically selected, resulting in the http request have two (different) Content-Type: entries.

It is possible to work around this by going into the Code tab and deleting the entry for the key contentType:. Do not delete the entire line, just the value. Otherwise it gets recreated with a default value of application/json. Save the thing and don’t ever touch it again :slight_smile:

It would be nice if this Content-Type header was available in the list to select from.

For reference: working definition of http thing for getting data from https://api.eiswarnung.de/:

Populating the items is done by linking all items to the same channel resultString using different JSONPATH transformations

UID: http:url:http_eiswarnung
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: true
  headers:
    - Content-Type=application/x-www-form-urlencoded
  baseURL: https://api.eiswarnung.de/
  delay: 0
  stateMethod: POST
  refresh: 14400
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
location: Draußen
channels:
  - id: resultString
    channelTypeUID: http:string
    label: Eiswarnung komplettes JSON
    description: ""
    configuration:
      mode: READONLY
      stateContent: key=secretAPIkey&lat=50.123456&lng=9.123456
  - id: last-success
    channelTypeUID: http:request-date-time
    label: Last Success
    configuration: {}
  - id: last-failure
    channelTypeUID: http:request-date-time
    label: Last Failure
    configuration: {}

Hi, I use eiswarnung too.
My thing:

UID: http:url:Eiswarnung
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://api.eiswarnung.de/?key=xxx&lat=xx&lng=xxx
  delay: 0
  stateMethod: POST
  refresh: 43200
  commandMethod: GET
  contentType: application/json
  timeout: 3000
  bufferSize: 2048
channels:
  - id: EiswarnungText
    channelTypeUID: http:string
    label: EiswarnungText
    description: ""
    configuration:
      mode: READONLY
      stateTransformation: JSONPATH:$.result.forecastText

This works for over a year… I’m on openHab 4.2.2
Greets

Ah, I see you included the POST data in the baseURL. Didn’t think of that, good idea!
I thought (wrongly, apparently) the payload for the POST had to be in the body of the request.

Good to know, thanks for the response!