guzzle / uri-template Goto Github PK

License: MIT License

PHP 97.39% Makefile 2.61%

uri-template's Introduction

Guzzle, PHP HTTP client

Guzzle is a PHP HTTP client that makes it easy to send HTTP requests and trivial to integrate with web services.

Simple interface for building query strings, POST requests, streaming large uploads, streaming large downloads, using HTTP cookies, uploading JSON data, etc...
Can send both synchronous and asynchronous requests using the same interface.
Uses PSR-7 interfaces for requests, responses, and streams. This allows you to utilize other PSR-7 compatible libraries with Guzzle.
Supports PSR-18 allowing interoperability between other PSR-18 HTTP Clients.
Abstracts away the underlying HTTP transport, allowing you to write environment and transport agnostic code; i.e., no hard dependency on cURL, PHP streams, sockets, or non-blocking event loops.
Middleware system allows you to augment and compose client behavior.

$client = new \GuzzleHttp\Client();
$response = $client->request('GET', 'https://api.github.com/repos/guzzle/guzzle');

echo $response->getStatusCode(); // 200
echo $response->getHeaderLine('content-type'); // 'application/json; charset=utf8'
echo $response->getBody(); // '{"id": 1420053, "name": "guzzle", ...}'

// Send an asynchronous request.
$request = new \GuzzleHttp\Psr7\Request('GET', 'http://httpbin.org');
$promise = $client->sendAsync($request)->then(function ($response) {
    echo 'I completed! ' . $response->getBody();
});

$promise->wait();

Help and docs

We use GitHub issues only to discuss bugs and new features. For support please refer to:

Installing Guzzle

The recommended way to install Guzzle is through Composer.

composer require guzzlehttp/guzzle

Version Guidance

Version	Status	Packagist	Namespace	Repo	Docs	PSR-7	PHP Version
3.x	EOL (2016-10-31)	`guzzle/guzzle`	`Guzzle`	v3	v3	No	>=5.3.3,<7.0
4.x	EOL (2016-10-31)	`guzzlehttp/guzzle`	`GuzzleHttp`	v4	N/A	No	>=5.4,<7.0
5.x	EOL (2019-10-31)	`guzzlehttp/guzzle`	`GuzzleHttp`	v5	v5	No	>=5.4,<7.4
6.x	EOL (2023-10-31)	`guzzlehttp/guzzle`	`GuzzleHttp`	v6	v6	Yes	>=5.5,<8.0
7.x	Latest	`guzzlehttp/guzzle`	`GuzzleHttp`	v7	v7	Yes	>=7.2.5,<8.4

Security

If you discover a security vulnerability within this package, please send an email to [email protected]. All security vulnerabilities will be promptly addressed. Please do not disclose security-related issues publicly until a fix has been announced. Please see Security Policy for more information.

License

Guzzle is made available under the MIT License (MIT). Please see License File for more information.

For Enterprise

Available as part of the Tidelift Subscription

The maintainers of Guzzle and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

uri-template's People

Contributors

Stargazers

Watchers

Forkers

elias33333 mouragilvan seanpm2001 antoinewattier joyparty kornaphp

uri-template's Issues

[RFC] Handling of bad templates

The current spec recommends explicitly rejecting templates of invalid syntax, and indeed there are tests to check this happens. We currently don't do that. Should we bother? How hard would this be to do correctly?

Set up github actions

If anyone wants to do this, that'd be great. If not, I will do it, eventually. :)

[RFC] GuzzleHttp\Uri\Template

Change GuzzleHttp\Utility\UriTemplate to GuzzleHttp\Uri\Template. This name is what was originally used in development of Guzzle 4, actually, and I think is better than a generic utility namespace.

pct-encoded reserved character(%2F) was encoded twice

PHP version: 8.1.3

Description

As of a community reporting, while the uri was already contains the pct-encoded(reserved characters) component, eg: AIO%2FFR. The {+var} syntax is explained this one as of AIO%252FFR. It is leading to misinterpreting the original percent data octet string.

I've also checked the RFC3986 and RFC6570 specifications.

RFC3986 2.4. When to Encode or Decode was mentioned there:

Because the percent ("%") character serves as the indicator for
percent-encoded octets, it must be percent-encoded as "%25" for that
octet to be used as data within a URI. Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.

RFC6570 3.2.1. Variable Expansion was mentioned there:

The allowed set for a given expansion depends on the expression type:
reserved ("+") and fragment ("#") expansions allow the set of
characters in the union of ( unreserved / reserved / pct-encoded ) to
be passed through without pct-encoding, whereas all other expression
types allow only unreserved characters to be passed through without
pct-encoding. Note that the percent character ("%") is only allowed
as part of a pct-encoded triplet and only for reserved/fragment
expansion: in all other cases, a value character of "%" MUST be pct-
encoded as "%25" by variable expansion.

The pct-encoded reserved character(%2F) may pass through but it was encoded the char(%) to %25. It is mismatched the specs.

How to reproduce

<?php

require_once './vendor/autoload.php';

use GuzzleHttp\UriTemplate\UriTemplate;
echo UriTemplate::expand('merchant-service/images/{+slot}', ['slot' => 'AIO%2FFR']);
// result: merchant-service/images/AIO%252FFR
// Actually, there was required the url like this: `merchant-service/images/AIO%2FFR`

Possible Solution

Additional context

Test against the spec

https://github.com/uri-templates/uritemplate-test