Custom `ContentService` responses (e.g., XML/RSS) are not respected and get serialized to `{}`

[felipepmdias]

Hi! First of all, thank you again for your work on Boot.gs — it’s a very valuable project that significantly improves structure and developer experience in Google Apps Script.

I’m opening a few issues as I explore the framework more deeply, with the intention of contributing and helping improve it. If this becomes inconvenient or noisy in any way, please feel free to let me know and I’ll stop — no problem at all.

---

Problem

Currently, it is not possible to return custom response types beyond the predefined formats (JSON, text, HTML) when using HTTP controllers.

For example, when trying to return an XML (RSS) response using ContentService, the response is not delivered correctly. Instead, the client receives an empty object {}.

Example:

@Get('/feed/{id}')
public getPodcastFeed(@Param('id') id: string): GoogleAppsScript.Content.TextOutput {
  const xml = this.podcastService.getFeedFile(Number(id));

  return ContentService
    .createTextOutput(xml)
    .setMimeType(ContentService.MimeType.RSS);
}

Expected behavior:

• Response body contains the XML
• Content-Type: application/rss+xml

Actual behavior:

{}

---

🔍 Root Cause

From analyzing the current implementation, it seems that all controller return values are being passed through a response builder that serializes the result, regardless of its type.

The logic likely resembles something like:

return JSON.stringify(result);

or:

return ResponseBuilder.wrap(result);

This causes TextOutput (and potentially other native GAS response types) to be treated as plain objects and serialized incorrectly, resulting in {}.

---

Suggested Solution

Before applying any transformation or serialization, the framework should detect if the returned value is already a valid ContentService response and return it as-is.

Option 1 (explicit type check):

if (result instanceof ContentService.TextOutput) {
  return result;
}

Option 2 (more generic / flexible):

const isNativeGasObject = body && typeof body === 'object' && 
  ('setMimeType' in body || 'setTitle' in body || 'getContent' in body);

if (isNativeGasObject) {
  return body;
}

This approach is more robust and future-proof, as it allows handling different native GAS response types without tightly coupling to a specific class.

---

🚀 Why this matters

This change would enable support for:

• RSS feeds (application/rss+xml)
• XML APIs
• File responses
• Any custom MIME type supported by GAS

Without this, developers are limited to JSON/text/HTML responses, which restricts many valid use cases.

---

Final note

Again, thank you for building and maintaining this project — it’s genuinely very useful. I’m opening these issues in the spirit of collaboration and improvement.

[MaksymStoianov]

Hi @felipepmdias! 👋

Please, don't worry about 'noise'–your issues are incredibly well-documented and provide high-value technical insights. This is exactly what the project needs to grow!

The main goal of Boot.gs is to ensure your code doesn't care how it’s being called, it should work exactly the same for both doGet/doPost and google.script.run.

Because Google Apps Script (GAS) can be somewhat restrictive with headers, I implemented a Virtual Transport Layer. It essentially "tucks" your request metadata (like the HTTP method and path) into GET parameters so the framework handles the heavy lifting for you, regardless of the environment.

Currently, the response format is strictly determined by the Accept key inside the headers parameter.

Virtual Request Parameters

To simulate a standard HTTP request, you pass these key parameters to the framework:

• method: Simulates the HTTP method (GET, POST, PUT, DELETE, etc.).
• pathname: The virtual resource path (e.g., /api/users/1).
• headers: A JSON-stringified object containing the Accept header to determine the response format.

Caution

Important Security Note: Do not pass secrets in headers!

Because the Virtual Transport Layer passes all request metadata (including headers) via URL query parameters, you must never include sensitive information like API keys, Bearer tokens, or passwords inside the headers object.

Why? URLs (and their query strings) are frequently logged in plain text by browsers, proxy servers, IT network monitors, and Google's own access logs. Exposing secrets in the URL makes them highly vulnerable to interception. If you need to send authentication tokens or sensitive data, always pass it securely within the payload body of a POST request instead.

Supported Response Types (Accept MimeTypes)

To receive data in a specific format, pass the corresponding MimeType inside the headers parameter.

Enum Value	MimeType	Resulting Output	Context
JSON	application/json	Standard JSON via ContentService	External API (Web App)
TEXT	text/plain	Plain text output	External API (Web App)
HTML	text/html	HTML content via HtmlService	Web Page (Browser)
GOOGLE_JSON	google/json	Optimized JSON string	Internal (google.script.run)
GOOGLE_TEXT	google/plain	Direct string (no wrapper)	Internal (google.script.run)

Tip

Use GOOGLE_JSON or GOOGLE_TEXT for internal communication within the HTMLService. This bypasses the overhead of ContentService and delivers much faster response times. For external integrations (like third-party webhooks), stick to standard JSON, TEXT, or HTML.

How to Call the API

Depending on your environment, adapt your request format to ensure optimal performance and compatibility.

1. Internal Usage (google.script.run)

Use this when building Sidebars, Modals, or Add-ons.

• Target MimeType: google/json or google/plain.

Example (Client-side JS):

const path = '/api/users/123';
const method = 'GET';
const headers = JSON.stringify({
  "Accept": "google/json"
});

// Constructing the Virtual Transport Event
const event = {
  pathInfo: path,
  parameter: {
    method,
    pathname: path,
    headers
  },
  parameters: {
    method: [method],
    pathname: [path],
    headers: [headers]
  },
  queryString: `method=${method}&pathname=${encodeURIComponent(path)}&headers=${encodeURIComponent(headers)}`
};

google.script.run
  .withSuccessHandler(response => {
    // Parse the optimized string response
    const result = typeof response === 'string' ? JSON.parse(response) : response;
    
    console.log("Status:", result.status);
    console.log("Data:", result.body);
  })
  .doGet(event); // Note: Use .doPost(event) if the method is POST, PUT, or DELETE!

2. External Usage (Web App URL / Browser)

Use this when you are accessing the script via a direct link, a webhook, or a third-party service. This returns a standard GAS TextOutput or HtmlOutput (browser address bar, postman, webhooks).

• Target MimeType: application/json, text/html, or text/plain.

Example API Request URL:

• Base URL: https://script.google.com/.../exec
• Parameters:
  • method=GET
  • pathname=${encodeURIComponent("/feed/json")}
  • headers=${encodeURIComponent(JSON.stringify({ "Accept": "application/json" })}

Final URL:
https://script.google.com/.../exec?method=GET&pathname=%2Ffeed%2Fjson&headers=%7B%22Accept%22%3A%22application%2Fjson%22%7D

Example HTML Page URL:
To render a dashboard directly in the browser:
https://script.google.com/.../exec?pathname=dashboard

Response Wrapping Logic

The framework automatically wraps your controller's return value based on the pathname you requested:

A. API Context (Path starts with apiPrefix)

If the path starts with your configured API prefix (e.g., /api/users), the framework returns a full HTTP-like payload:

{
  "status": 200,
  "statusText": "OK",
  "headers": { "Content-Type": "application/json" },
  "body": { "id": 123, "name": "John Doe" }
}

B. Standard Context (Everything else)

If the path is outside the API prefix (e.g., a simple /home route), the framework bypasses the payload wrapper and returns only the body directly.

Bonus: Custom Axios Adapter

Building those google.script.run payloads manually can get a bit tedious. To make things easier, I've already built a custom axios adapter specifically for GAS Web Apps, Add-ons, and Modals.

It completely abstracts away the virtual transport layer, meaning you can just write standard axios.get() or axios.post() requests in your frontend, and the adapter handles all the google.script.run event routing behind the scenes.

I'm planning to publish it soon, but let me know if this is something you'd find useful right now, and I can share it with you!

---

P.S. Your suggestion for XML/RSS support is perfect! I will expand the HeaderAcceptMimeType enum and update the ResponseBuilder to respect native GAS objects like TextOutput.
This will be included in the next update!

[felipepmdias]

Hi @MaksymStoianov !

Thank you for the very detailed explanation — it really helped me understand the reasoning behind the current design and the proposed changes.

I found the idea of the Virtual Transport Layer quite clever and very useful, especially for unifying the behavior between Web Apps and google.script.run.

Appreciate your work and the improvements you’re bringing to the project!

[MaksymStoianov]

Hi @felipepmdias!

You're very welcome! I'm glad the explanation of the Virtual Transport Layer resonated with you.

Actually, thanks to your previous suggestions and our discussion, I’ve slightly rethought the core logic of how response types are handled.

I have also updated the README to reflect these changes and provide more clarity on the improved logic.

Thanks again for your valuable input – it’s exactly what helps the project move in the right direction!