starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 16:55:59 +03:00

[GH-ISSUE #869] Response content-type as `text/html` with content in `json` cause content area display empty #298

New issue

Closed

opened 2026-03-16 14:25:28 +03:00 by kerem · 8 comments

kerem commented

2026-03-16 14:25:28 +03:00

Owner

Originally created by @BLumia on GitHub (May 13, 2020).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/869

Originally assigned to: @AndrewBastin on GitHub.

Describe the bug
When the returend content-type is text/plain or text/html but the actual content is a json, the preview shows empty.

To Reproduce

I did a quick and dirty server side demo implementation in go:

package main

import "fmt"
import "log"
import "strings"
import "strconv"
import "net/http"

func FileServer(response http.ResponseWriter, request *http.Request) {
	path := request.URL.Path

	var contentType string;
	responseType := path[strings.LastIndex(path, "/"):]

	switch responseType {
	case "/json":
        contentType = "application/json";
	case "/plain":
        contentType = "text/plain";
	default:
        contentType = "text/html";
	}
	
	response.Header().Set("content-type", contentType)

    fmt.Fprintf(response, "{\"status\": 200, \"content-type\": \"%s\"}", contentType)
}

func Controller(response http.ResponseWriter, request *http.Request) {
	FileServer(response, request)
}

func main() {
	PortNumber := 4000

	fmt.Println("Now listening port: " + strconv.Itoa(PortNumber))

	http.HandleFunc("/", Controller)
	err := http.ListenAndServe(":"+strconv.Itoa(PortNumber), nil)
	if err != nil {
		log.Fatal(err)
	}
}

Do compile it (go compile main.go) and run it, then request the following address:

http://127.0.0.1:4000/ : response "text/html" as content-type, preview is empty.
http://127.0.0.1:4000/plain : response "text/plain" as content-type, preview is empty.
http://127.0.0.1:4000/json : response "application/json" as content-type, preview is expected.

Also, when the preview is empty, try toggle "Preview HTML" button, then it will show a [object Object], but "Download File" icon button can download the actual response content.

Expected behavior

When response content-type is html or plain, the preview area should able to at least show the raw content instead of shows empty.

Screenshots

Following image is what it shows when request http://127.0.0.1:4000/ with the above demo server program running.

Desktop (please complete the following information):

OS: Windows 10 (I guess it doesn't matter what OS I am using)
Browser chrome
Version 81.0.4044.138

Let me know if you need any additional context to resolve this issue. Hope that helps.

Originally created by @BLumia on GitHub (May 13, 2020). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/869 Originally assigned to: @AndrewBastin on GitHub. **Describe the bug** When the returend content-type is `text/plain` or `text/html` but the actual content is a json, the preview shows empty. **To Reproduce** I did a quick and dirty server side demo implementation in go: ``` go package main import "fmt" import "log" import "strings" import "strconv" import "net/http" func FileServer(response http.ResponseWriter, request *http.Request) { path := request.URL.Path var contentType string; responseType := path[strings.LastIndex(path, "/"):] switch responseType { case "/json": contentType = "application/json"; case "/plain": contentType = "text/plain"; default: contentType = "text/html"; } response.Header().Set("content-type", contentType) fmt.Fprintf(response, "{\"status\": 200, \"content-type\": \"%s\"}", contentType) } func Controller(response http.ResponseWriter, request *http.Request) { FileServer(response, request) } func main() { PortNumber := 4000 fmt.Println("Now listening port: " + strconv.Itoa(PortNumber)) http.HandleFunc("/", Controller) err := http.ListenAndServe(":"+strconv.Itoa(PortNumber), nil) if err != nil { log.Fatal(err) } } ``` Do compile it (`go compile main.go`) and run it, then request the following address: - `http://127.0.0.1:4000/` : response "text/html" as content-type, preview is empty. - `http://127.0.0.1:4000/plain` : response "text/plain" as content-type, preview is empty. - `http://127.0.0.1:4000/json` : response "application/json" as content-type, preview is expected. Also, when the preview is empty, try toggle "Preview HTML" button, then it will show a `[object Object]`, but "Download File" icon button can download the actual response content. **Expected behavior** When response content-type is html or plain, the preview area should able to at least show the raw content instead of shows empty. **Screenshots** Following image is what it shows when request `http://127.0.0.1:4000/` with the above demo server program running. ![response content area shows empty](https://user-images.githubusercontent.com/10095765/81766804-7053b600-9509-11ea-879b-4ce9f5338a52.png) ![response content area shows object Object](https://user-images.githubusercontent.com/10095765/81766831-7fd2ff00-9509-11ea-87fb-8f6d0c37c33d.png) **Desktop (please complete the following information):** - OS: Windows 10 (I guess it doesn't matter what OS I am using) - Browser chrome - Version 81.0.4044.138 Let me know if you need any additional context to resolve this issue. Hope that helps.

kerem

2026-03-16 14:25:28 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-16 14:25:43 +03:00

Author

Owner

@liyasthomas commented on GitHub (May 13, 2020):

Response content-type as text/html with content in json
Is this an actual real-life case or just for testing? I've never seen such an endpoint.

@liyasthomas commented on GitHub (May 13, 2020): > Response content-type as `text/html` with content in `json` Is this an actual real-life case or just for testing? I've never seen such an endpoint.

kerem commented

2026-03-16 14:25:49 +03:00

Author

Owner

@BLumia commented on GitHub (May 13, 2020):

Response content-type as text/html with content in json
Is this an actual real-life case or just for testing? I've never seen such an endpoint.

It's in real life. I just got this issue today with an endpoint return text/html with a json content. Since that service is not exposed to public usage so I cannot link the real API here, sorry about that.

I agree that endpoint implementation might not do the best practice, but still, I do think the content area in postwoman should at least display the raw content if the content-type is text/html or text/plain, instead of display a [object Object]...

@BLumia commented on GitHub (May 13, 2020): > > Response content-type as `text/html` with content in `json` > > Is this an actual real-life case or just for testing? I've never seen such an endpoint. It's in real life. I just got this issue today with an endpoint return `text/html` with a json content. Since that service is not exposed to public usage so I cannot link the real API here, sorry about that. I agree that endpoint implementation might not do the best practice, but still, I do think the content area in postwoman should at least display the raw content if the content-type is `text/html` or `text/plain`, instead of display a `[object Object]`...

kerem commented

2026-03-16 14:25:54 +03:00

Author

Owner

@liyasthomas commented on GitHub (May 13, 2020):

Issue has been acknowledged. I'm working on a fix.

@liyasthomas commented on GitHub (May 13, 2020): Issue has been acknowledged. I'm working on a fix.

kerem commented

2026-03-16 14:25:59 +03:00

Author

Owner

@AndrewBastin commented on GitHub (May 18, 2020):

@liyasthomas are you working on this ?

Else I will take it up ^_^

@AndrewBastin commented on GitHub (May 18, 2020): @liyasthomas are you working on this ? Else I will take it up ^_^

kerem commented

2026-03-16 14:26:04 +03:00

Author

Owner

@liyasthomas commented on GitHub (May 18, 2020):

@AndrewBastin Actually I couldn't find why this behaviour happened. The contents passed to the editor seems to be receiving an object type. You can look into it.

@liyasthomas commented on GitHub (May 18, 2020): @AndrewBastin Actually I couldn't find why this behaviour happened. The contents passed to the editor seems to be receiving an `object` type. You can look into it.

kerem commented

2026-03-16 14:26:09 +03:00

Author

Owner

@AndrewBastin commented on GitHub (May 18, 2020):

I am working on it.

~~Seems like it is a weird Ace Editor bug.~~

EDIT: Well, upon on further investigation, it is due to the default behaviour of axios to try parsing the JSON even if the content-type doesn't say it is JSON

@AndrewBastin commented on GitHub (May 18, 2020): I am working on it. ~~Seems like it is a weird Ace Editor bug.~~ EDIT: Well, upon on further investigation, it is due to the default behaviour of axios to try parsing the JSON even if the content-type doesn't say it is JSON

kerem commented

2026-03-16 14:26:14 +03:00

Author

Owner

@AndrewBastin commented on GitHub (May 19, 2020):

This bug is caused due to the default behaviour of axios to take string responses and try to parse them to JSON objects even if the content type is not for a JSON response.

So, when a valid returned eventhough it is set to text/plain, it will try parsing it and get the JSON object. Then Postwoman can't figure out what to do with JSON object, causing the issue.

This behaviour is overridden on the update to the AxiosStrategy in my PR (#881).

But, we have to handle it in all the places where we use Axios.

The browser extension will receive the fix to this in the coming days in a 0.7 update.
UPDATE: Browser extension version 0.7 is live on Firefox and Chrome

Meanwhile, if the proxy uses axios, that should be handled as well @NBTX .

@AndrewBastin commented on GitHub (May 19, 2020): This bug is caused due to the default behaviour of axios to take string responses and try to parse them to JSON objects even if the content type is not for a JSON response. So, when a valid returned eventhough it is set to `text/plain`, it will try parsing it and get the JSON object. Then Postwoman can't figure out what to do with JSON object, causing the issue. This behaviour is overridden on the update to the AxiosStrategy in my PR (#881). But, we have to handle it in all the places where we use Axios. The browser extension will receive the fix to this in the coming days in a 0.7 update. UPDATE: Browser extension version 0.7 is live on Firefox and Chrome Meanwhile, if the proxy uses axios, that should be handled as well @NBTX .

kerem commented

2026-03-16 14:26:19 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Jun 15, 2020):

@NBTX, I haven't personally tested this with the proxy, but is this an issue on the proxy ?

@liyasthomas ?

@AndrewBastin commented on GitHub (Jun 15, 2020): @NBTX, I haven't personally tested this with the proxy, but is this an issue on the proxy ? @liyasthomas ?

kerem referenced this issue

2026-03-16 14:42:15 +03:00

[GH-ISSUE #908] How to upload a file with a post request #323

kerem referenced this issue

2026-03-16 17:28:26 +03:00

[GH-ISSUE #2594] [feature]: Send binary file as body #862

kerem referenced this issue

2026-03-17 00:14:02 +03:00

[PR #297] [MERGED] 📱 Popovers on mobile devices #2536