UTF Issue when shortening a URL with https

[og-shg]

If I shorten this URL
https://search.spokanehomeguy.com/search/detail/202195346?s[page]=1&s[locations][0][city]=Spokane&s[locations][0][state]=WA

The script spins and spins and does not produce an output.

If I remove the "s"
http://search.spokanehomeguy.com/search/detail/202195346?s[page]=1&s[locations][0][city]=Spokane&s[locations][0][state]=WA

It shortens just fine.
How can I fix this without constantly adjusting the input?

Error Log:
[18-Jan-2024 22:48:28 UTC] PHP Fatal error: Uncaught ValueError: mb_convert_encoding(): Argument #3 ($from_encoding) contains invalid encoding "utf" in /home/fbvvkrxo4bco/public_html/includes/functions.php:933
Stack trace:
#0 /home/fbvvkrxo4bco/public_html/includes/functions.php(933): mb_convert_encoding()
#1 /home/fbvvkrxo4bco/public_html/includes/functions-shorturls.php(97): yourls_get_remote_title()
#2 /home/fbvvkrxo4bco/public_html/admin/admin-ajax.php(21): yourls_add_new_link()
#3 {main}
thrown in /home/fbvvkrxo4bco/public_html/includes/functions.php on line 933

[dgw]

The markup served by this URL is not valid. Specifically, this is an error:

<meta charSet="utf=8"/>

Note the = inside the value, which should be a -. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#charset

I'm not positive why there's a difference between http:// and https://, but they seem to do some user-agent sniffing to decide whether to redirect the client or not, e.g. a browser is redirected from http:// to https:// but curl instead gets a very brief "Hello Developer Person!" page with a comment asking to use the HTTPS link directly.

The fatal error comes from inside YOURLS's attempt to convert an unrecognized encoding interpreted as utf into proper utf-8:

YOURLS/includes/functions.php

Lines 911 to 938 in be573de

	// Now we have a title. We'll try to get proper utf8 from it.
	// Get charset as (and if) defined by the HTML meta tag. We should match
	// <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	// or <meta charset='utf-8'> and all possible variations: see https://gist.github.com/ozh/7951236
	if ( preg_match( '/<meta[^>]*charset\s*=["\' ]*([a-zA-Z0-9\-_]+)/is', $content, $found ) ) {
	$charset = $found[ 1 ];
	unset( $found );
	}
	else {
	// No charset found in HTML. Get charset as (and if) defined by the server response
	$_charset = current( $response->headers->getValues( 'content-type' ) );
	if ( preg_match( '/charset=(\S+)/', $_charset, $found ) ) {
	$charset = trim( $found[ 1 ], ';' );
	unset( $found );
	}
	}
	// Conversion to utf-8 if what we have is not utf8 already
	if ( strtolower( $charset ) != 'utf-8' && function_exists( 'mb_convert_encoding' ) ) {
	// We use @ to remove warnings because mb_ functions are easily bitching about illegal chars
	if ( $charset ) {
	$title = @mb_convert_encoding( $title, 'UTF-8', $charset );
	}
	else {
	$title = @mb_convert_encoding( $title, 'UTF-8' );
	}
	}

YOURLS should probably catch this error in case of an invalid charset value and try mb_convert_encoding() on the title again without specifying the source charset. The title potentially being mangled if the charset is incorrectly converted should be less of a problem than outright failing on invalid charset values as it does now.

Momentarily, I will create an issue from this discussion to track the proposed enhancement. See #3708

[og-shg]

Thanks so much, that would do it. I did submit a ticket to our vendor too to fix the problem on our end too. Thank you for your prompt response.