When doing $response->redirect("/somewhere/"), it would be nice if the redirect function added an extra header to the response, which was the name of the calling function that initiated the response. When there's a lot of _common scripts that all control things like auth, it can be a bit confusing.

There's already a withQueryValue which makes it easy to work with Uris that already have a query string. getQueryValue will eliminate the need of parsing the string each time.

Reloading the response will always keep the query string, but sometimes I want to throw it away. Needs a default bool.

https://developer.mozilla.org/en-US/docs/Web/API

There are a few classes in the WebAPI that have functionality shared by this implementation of PSR-7 which should be implemented.

Functions:

• Message::arrayBuffer() - Returns a promise
• Message::blob() - Returns a promise
• Message::formData() - Returns a promise
• Message::json() - Returns a promise
• Message::text() - Returns a promise

Properties:

• Response::ok
• Response::headers
• Response::redirected
• Response::status
• Response::statusText
• Response::type
• Response::uri
• Response::useFinalUri

• Request::cache
• Request::context
• Request::credentials
• Request::destination
• Request::headers
• Request::integrity
• Request::method
• Request::mode
• Request::redirect
• Request::referrer
• Request::referrerPolicy
• Request::url

• The Headers class needs to have its methods made compatible (https://developer.mozilla.org/en-US/docs/Web/API/Headers).

• The FormData class needs fully implementing.

• The Stream class should be broken down into ReadableStream and WritableStream.

I would like to pass RequestMethod::GET to the first parameter of the RequestInterface constructor, but it expects a string.

If we're using PSR-7, the return type should actually be ServerRequestInterface as it's creating it from the globals of the server.

These two classes are fundamental to basic HTTP usage, but specifically need to be implemented to allow PHP.Gt/Fetch to reach its next stable release.

PhpGt/Fetch#99 relies on this issue.

Class list to implement:

• FormData
• URLSearchParams
• TypedArray
• DataView not supported for PHP (I think...)
• Blob
• FileUpload (or similarly named class)

It will be confusing because of PSR-7, but PHP.Gt strives for standards compliance, and PSR is specifically not a standard.

Headers do not care about case. Getting a value or checking a value shouldn't make any difference if it;s accept or Accept or ACCEPT.

The only header that should end early is Location as far as I can tell, but maybe there are more. Need to research before implementing.

HttpForbidden is not within the ClientError namespace as it should be, for example.

To increase testability and general code quality, the process of sending the Location header for a reload or redirect should be exposed as a function on the Response. This is only possible by having a callback stored for execution when the header is sent, which will allow WebEngine to intercept the response logic and exit early.

When dealing directly with the Request object, hyphenated headers are converted to underscores, which is incorrect.

See:

$request = $this->container->get(Request::class);
$pagination = null;
if($request->hasHeader("x_pagination")) {
	$pagination = $request->getHeaderLine("x_pagination");
}

The actual header name is x-pagination, as per this JavaScript:

fetch(location.href, {
	headers: {
		"x-pagination": page
	}
}).then(response => {
	// ...
});

There needs to be some documented feature for how to use FormData for posting data, and how to use some kind of FileUpload class to upload binary content over HTTP. Is there a PHP built in class for this?

Dependabot needs to be tamed, as per PhpGt/WebEngine#568

There is use of a custom PropertyGetter train within this repo - it doesn't need to be there now we've got https://github.com/PhpGt/PropFunc.

To be consistent with other areas of PHP.Gt, getString, getInt, etc. should be implemented.

PHPUnit 10 has removed a few functions in its Mocking library - this needs to be fixed, and while you're at it, introduce PHPMD and PHPCS and a matrix build system!

To increase PSR-15 compatibility, it would be super-useful to be able to create a Request object from the current global state, not requiring any Gt-specific objects at all.

Following on from PhpGt/Fetch#153, it would be nice to simulate the "await" keyword in JS:

JS version:

const response = await fetch("/api");
const jsonObject = await response.json();

PHP version:

$response = $http->awaitFetch("/api");
$jsonObject = $response->awaitJson();

An app I'm working on has a <0.1% session fail rate, but has a high traffic rate, so the issue is being brought to my attention every day or so. After researching what is causing the sessions to rotate, there's a strong indication that it only happens when a "relative" redirect is made.

If I'm right, the issue only happens after:

$response->redirect("./something/"); or $response->redirect("../"); for example.

When the Response is constructed, it could be passed the current request uri as an optional parameter - and if this parameter is present, it can use the available parts of the uri to normalise an absolute URI.

Will this solve the issue though?

Headers with multiple values are separated with a comma/semicolon (need clarification).

https://github.com/php-fig/http-message/blob/master/docs/PSR7-Usage.md#getting-array-of-value-from-a-header-also-applies-to-request

When constructing the headers, should this be parsed? For example, the default accept header from Firefox: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 - should this be split on the commas and added one by one?

Currently all of the classes in Http are immutable (with instead of set functions), but Headers are not. For consistency alone this should be changed, but it would also improve code cleanness throughout.

Apparently it's a good idea to use PSR-7 when writing libraries that implement URLs, Requests, Responses, etc. but I'm coming to the opinion that it really doesn't matter at all, and PSRs actually just get in the way of what you're trying to do.

If this library's intention was to be interoperable with other Http libraries, maybe it would be a good idea to implement PSRs, but who has ever inter-operated anything in PHP? You refactor and get the job done.

This is not a rant about PSR. It's great to have consistency. But this library is suffering, because PSRs are not compatible with web standards.