since 7.13, my fetch script returns this error when fetching a webpage: “failure: ERROR parsing http: there was no content-length or transfer-encoding”
This fetch script calls a page from an ethernet relay board in the lan.
It may be that the ethernet relay PCB doesn’t revert a specific field, and I have no control over this, but until routerOS 7.13, this was not an issue: fetch seemed to be more flexible at accommodating this and returning the fetched content.
I confirm that freshly released 7.13.4 still display this error message.
What can be done to provide fetch the same level of flexibility it had until 7.12.1?
MikroTik RouterOS 7.16.1
/tool fetch mode=http url=http://192.168.0.1/ output=user-with-headers
status: failed
failure: there was no content-length or transfer-encoding
Hi, I have thoroughly investigated this error, and it is due to an incorrect response from the server.
The header contains the Content-Type field but does NOT contain the Content-Length field, and this generates the error.
If the server responds with the Content-Type field, it MUST also enter the Content-Length field.
The combination are:
Content-Type and Content-Length
OR
Transfer-Encoding and Content-Length
It’s a problem of the server side that is not compliant with HTTP 1.1.
Header with error (don’t works with fetch)
Header correct with Content-Type (works with fetch)
Header correct with Transfer-Encoding (works with fetch)
Marco
I confirm this works fine, no idea what it does different in the background, but it is a perfect workaround.
Thank you very much!
BTW: I have also contacted Mikrotik support, they were very helpful and fixed it in the next release.
I understand it it most likely a broken server, but it seems there are too many of them to ignore it like self signed certs
But unfortunately, this still doesn’t work for me:
the http server does register the fetch and flip the switch accordingly
but on Mikrotik side, I still can’t parse the response, instead the same error message is thrown
The same behavior occured before this asynchronous scripting unfortunately.
Both codes return the same error message - running RouterOS version 7.16.2:
Thanks for the clarification.
Would you happen to have a link to the changelog to expectat in 7.18?
I can’t find much as currently 7.17 is in release candidate, and nothing on 7.18 is mentionned here: https://mikrotik.com/download/changelogs
Nightly builds are alpha/developers’ versions and nothing is guaranteed to enter to beta of same version. So there’s never any changelog for nightly builds. We’ve seen stuff removed from beta versions (rarely, but it did happen) so I’d guess that would happen even more often with alpha versions.
Nightly builds are sometimes (not often) offered to users which reported particular problem and devs managed to replicate and fix the problem … and offering nightly build with fix is some kind of courtesy to those users. Since same nightly builds contain other development code, they may break something else, which means that even user who receives such build, should use it with extreme care. Consider all the problem reports with beta/rc versions … and assume that alpha/nightly versions are almost certainly worse.
