Project

General

Profile

Actions

Bug #102529

open

Properly support HTTP Status Code 201 within extbase

Added by Daniel Siepmann 12 months ago. Updated 10 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2023-11-27
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Sources regarding HTTP Status Code 201:

The 201 status code can contain a location header, like the 3xx redirect status codes.
This is currently not possible via Extbase, as Extbase has hard checks regarding >= 300 within the Bootstrap class after internal dispatching of the request. Returning a redirect with 201 and a url is therefore not working as expected.

Browsers (tested with Firefox) probably do not support this, but APIs might need to conform to this.

The corresponding checks regarding >=300 could be adjusted to also check for 201 status code.

Actions #1

Updated by Chris Müller 12 months ago

  • Category set to Extbase
Actions #2

Updated by Christoph Lehmann 12 months ago

In v11 I had the similar issue in Extbase and ended up using http_response_code(xxx);

Actions #3

Updated by Stefan Bürk 10 months ago · Edited

Create your response with that http status code and header/data set, and
than throw a `PropagateResponseException with your response attached.

This skips the whole content object rendering stack and just returns your
complete response, unchanged.

Due to technical reasons, the content object rendering stack is not response
based, but string based. Therefore,additional information are lost.

Adding different selected status codes with special treatment is not the way
to go.

Extbase responses, albei basically a nice thing and making sense vor a MVC
thing, it was quite to early to add this.

The while.cobtent object rendering rendering stack requires a more extensive
refactoring ti support this better.

There have been thoughts about that already for v12, but sadly due to time
constraints, other things in thr todo list and no onr picking this up, there
is no solution for this right now in sight. Not evrn a poc. I would guess that
a solution may be breaking, so it won'get into v13.But we will see ... maybe
there is a chance to work at least on a poc for this in some weeks.

For now, use the exception technique which is a already known working solution,
also for.other use cases (retuning file contents and additonal response headers.etc).

And as a side effect, you can properly test your response with a functional
subrequest test using the typo3/testing-framework.


use Psr\Http\Message\ResponseFactoryInterface;
use TYPO3\CMS\Core\Http\Uri;
use TYPO3\CMS\Core\Http\PropagateResponseException;

// or use the extbase uri builder to build a uri (as string).
$uri = new Uri('https://some.domain.tld/path/');

// or let the responseFactory be injected by the DI
$responseFactory = GeneralUtility::makeInstance(ResponseFactoryInterface::class);
$response = $responseFactory
  ->createResponse(201, 'Created')
  ->withHeader('location', (string)$uri)
  ->withHeader('X-Redirect-By', 'Custom Extension Redirect');

throw new PropagateResponseException(
  $response,
  1705367285  // unix-timestamp, e.x. date +%s - not used as status code, the $response status code is used.
);

This can be used for all kinds of redirects, for example providing a file stream for
a larger file. Using this exception transport ALL headers are kept and used from the
provided response - as the while ContentObjectRenderer stack dismantling the response
and later creating a new one is skipped.

Actions

Also available in: Atom PDF