Request::getUri() issue

[8ctopus]

Trailing forward slash gets lost in your implementation while it's preserved in other libraries (for example httpsoft/http-message)

$request = new Request('GET', 'https://example.com/test/');
echo (string) $request->getUri(); // "https://example.com/test"

expected result:

$request = new Request('GET', 'https://example.com/test/');
echo (string) $request->getUri(); // "https://example.com/test/"

UPDATE: Looks like the behavior is intentional:

Capsule/src/Uri.php

Lines 238 to 243 in 0aa1c83

	if( empty($this->path) && $this->getAuthority() ){
	$url .= "/";
	}
	elseif( $this->path ) {
	$url .= ("/" . \trim($this->path, "/"));
	}

[brentscheffler]

@8ctopus Yes, it is intentional. Does this create a conflict or breaking change with anything? Or does it violate some RFC or standard or interface definition? I'm open to changing the behavior, but by changing the behavior, it could also introduce a breaking change for those already implementing this library.

[8ctopus]

I asked perplexity and here's the answer:

Great question! The URLs https://example.com/test/ (with a trailing slash) and https://example.com/test (without a trailing slash) can be different, depending on how the web server is configured. Here’s a clear breakdown:

Technical Difference

• With trailing slash (/test/):

  • Typically refers to a directory or folder.

  • Example: https://example.com/test/ would usually serve the content inside the test directory, often looking for an index.html or similar default file.

• Without trailing slash (/test):

  • Often refers to a file named test.

  • Example: https://example.com/test might look for a file called test (with no extension) in the root directory.

Server Behavior

• Redirects: Many web servers (like Apache or Nginx) will automatically redirect one version to the other, but this is not guaranteed.

• Content: If the server is configured to treat them as different, they can serve different content or one may return a 404 error while the other works.

SEO and Best Practice

• Canonicalization: Search engines treat them as two different URLs unless told otherwise (with redirects or canonical tags). This can affect SEO if both are accessible and serve the same content.

• Consistency: It’s best to pick one style and stick with it for your site’s URLs.

Example

• https://example.com/test/ → Might show a list of files or an index page.

• https://example.com/test → Might download a file or show a different resource.

Summary Table

URL | Typical Meaning | Can be Different? -- | -- | -- https://example.com/test/ | Directory (folder) | Yes https://example.com/test | File (named "test") | Yes

In summary:
They are not always the same. Whether they are treated as the same or different depends on the server setup. Always check your server configuration and use consistent URLs for best results!

Add to follow-up

1. https://example.com/test/
2. https://example.com/test

[brentscheffler]

@8ctopus I have a quick fix that preserves trailing slashes from paths (if one was provided), but it could introduce a breaking change. For example, if trailing slashes are always trimmed, the user may be adding or modifying the URL that is generated from the Uri class. Essentially, we are breaking established behavior, regardless of whether that behavior is actually wanted or expected.

For example, with current functionality/behavior:

$uri = UriFactory::fromString("https://api.example.com/some/resource/");
$final_uri = (string) $uri . "/resource_identifier"; 
echo $final_uri; // "https://api.example.com/some/resource/resource_identifier";

Changing behavior of preserving trailing forward slash:

$uri = UriFactory::fromString("https://api.example.com/some/resource/");
$final_uri = (string) $uri . "/resource_identifier"; 
echo $final_uri; // "https://api.example.com/some/resource//resource_identifier";

Notice the double forward slash in the above example: resource//resource_identifier.

We can add this change for the next major release (4.0). When that is, I don't know. But for now, I think this has to remain the same.

[8ctopus]

@brentscheffler I understand your concern and the breaking change. In the end, it's up to you whether or not you feel like implementing this change is good for Capsule or not. As I said a while ago, I'm using Shuttle which is awesome, but rarely using Capsule because of issues such as the one I reported here. If you remember, I suggested removing the dependency of Shuttle on Capsule so that the dev can choose his Http Request implementation.