Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[HttpFoundation] Fix support of custom mime types with parameters#18255

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:2.3fromGuilhemN:MIMETYPE
Mar 25, 2016

Conversation

@GuilhemN
Copy link
Contributor

QA
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsFriendsOfSymfony/FOSRestBundle#1399
LicenseMIT

When using mime types with parameters,getFormat won't return the expected format as illustrated:

$request =newRequest();$request->setFormat('custom','app/foo;param=bar');$request->getFormat('app/foo;param=bar');// will return null as the parameters are removed

So my proposal is to search the format corresponding to a mime type with its raw value or with the its parameters removed.

@GuilhemNGuilhemN changed the title[Request] Fix support of custom mime types with parameters[HttpFoundation] Fix support of custom mime types with parametersMar 21, 2016
if (in_array($mimeType, (array)$mimeTypes)) {
if (in_array($extendedMimeType, (array)$mimeTypes)) {
return$format;
}elseif (isset($mimeType) &&in_array($mimeType, (array)$mimeTypes)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Should be justif notelseif as you callreturn in firstif.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Good catch, thank you

* @return string|null The format (null if not found)
*/
publicfunctiongetFormat($mimeType)
publicfunctiongetFormat($extendedMimeType)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think it's necessary to change this variable name.$mimeType should be enough. It doesn't matter if the MIME type has parameters or not, both are MIME types.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

How would we call the$mimeType without parameters then?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

From the outside of this method, we always pass a MIME type, so I think that the argument should be called$mimeType. Internally you also check the MIME type without arguments, so maybe that could be called$canonicalMimeType ?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍 changed.

@GuilhemNGuilhemNforce-pushed theMIMETYPE branch 2 times, most recently from70d2130 toe75d7f0CompareMarch 23, 2016 17:10
@fabpot
Copy link
Member

👍

if (in_array($mimeType, (array)$mimeTypes)) {
return$format;
}
if (isset($canonicalMimeType) &&in_array($canonicalMimeType, (array)$mimeTypes)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I would probably rather initialise$canonicalMimeType withnull and omit theisset() check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

But this would force to callin_array() which is slower in case there is no cannonical mime-type, theisset() here prevents this useless check (in_array(null, (array) $mimeTypes)).

Instead ofisset() when the variable is initialized withnull, could be strict check:

if (null !==$canonicalMimeType &&in_array($canonicalMimeType, (array)$mimeTypes)) {}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

yes, that check should be added then instead ofisset()

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

updated.

@xabbuh
Copy link
Member

👍

Status: Reviewed

@fabpot
Copy link
Member

Thank you @Ener-Getick.

@fabpotfabpot merged commitf7ad285 intosymfony:2.3Mar 25, 2016
fabpot added a commit that referenced this pull requestMar 25, 2016
…ameters (Ener-Getick)This PR was merged into the 2.3 branch.Discussion----------[HttpFoundation] Fix support of custom mime types with parameters| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |FriendsOfSymfony/FOSRestBundle#1399| License       | MITWhen using mime types with parameters, ``getFormat`` won't return the expected format as illustrated:```php$request = new Request();$request->setFormat('custom', 'app/foo;param=bar');$request->getFormat('app/foo;param=bar');// will return null as the parameters are removed```So my proposal is to search the format corresponding to a mime type with its raw value or with the its parameters removed.Commits-------f7ad285 [Request] Fix support of custom mime types with parameters
@GuilhemNGuilhemN deleted the MIMETYPE branchMarch 25, 2016 16:29
This was referencedMar 25, 2016
@fabpotfabpot mentioned this pull requestApr 29, 2016
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@GuilhemN@fabpot@xabbuh@stloyd@javiereguiluz@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp