Not able to set charset in QNetworkReply header for custom url schemes

Bug #1569231 reported by Dan Chapman  on 2016-04-12
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Oxide
Medium
Unassigned

Bug Description

Not sure if this is a bug or i'm doing something wrong.

In Dekko when trying to set the charset like QNetworkReply::setHeader(QNetworkRequest::ContentTypeHeader, QString("text/html; charset=utf-8")) the page get's rendered as the raw html (See the attached image). So the charset has to be omitted in order to display the formatted content.

The Qt docs imply i am correct in trying to set the charset this way. Is there some other way i'm supposed to do this with Oxide's QNetworkAccessManager bridge?

Cheers

Dan

Dan Chapman  (dpniel) wrote :
description: updated
Chris Coulson (chrisccoulson) wrote :

I suspect this is because we take the entire Content-Type string and use it as the mime-type. We don't parse it in to its components (mime-type/charset)

Changed in oxide:
status: New → Triaged
importance: Undecided → Medium
Chris Coulson (chrisccoulson) wrote :

I'm fairly busy at the moment, but this would be a fairly easy fix for someone to take:

- net/http/http_util.h has a helper for this (net::HttpUtil::ParseContentType).
- This would need using in oxide::qt::URLRequestDelegatedJob::OnDidReceiveResponse, which would also need to record the charset as well as the mime type.
- We'd need to implement net::URLRequestJob::GetCharset.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments