Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

410-gone status not generated #31

Open
mficzel opened this issue Jan 29, 2019 · 9 comments
Open

410-gone status not generated #31

mficzel opened this issue Jan 29, 2019 · 9 comments

Comments

@mficzel
Copy link
Member

mficzel commented Jan 29, 2019

The creating of 410-Gone status does not work anymore. I am not sure when and how this happened. I can confirm this problem exists back to Neos 3.2 up to 4.2. It is possible that the new-ui is somehow involved but i have no setups any more without the new UI to verify this.

I can confirm that the problem lies in the neosadapter and not the redirecthandler since existing redirects with 410-status are still rendererd.

@mficzel mficzel changed the title 410 Gone Status not generated 410-gone status not generated Jan 29, 2019
@mficzel
Copy link
Member Author

mficzel commented Jan 29, 2019

@gerhard-boden do you know about this. As far as i see the 410 feature is not covered in the behat-tests yet but this might be quite easy.

@gerhard-boden
Copy link
Contributor

Yes, should be very easy to write an behat operation that checks the statusCode of the generated redirect, pretty much the same as https://github.com/neos/redirecthandler-neosadapter/blob/master/Tests/Behavior/Features/Bootstrap/RedirectOperationTrait.php#L59 but just for the status code

mficzel added a commit to mficzel/redirecthandler-neosadapter that referenced this issue Jan 30, 2019
If a node cannot be read in the create redirect step it is considered to have been deleted and
the removeNodeRedirect method is triggered.

fixes: neos#31
@kitsunet
Copy link
Member

kitsunet commented Apr 4, 2019

Important, I feel it's rather dangerous to set this automatically as it is fully cacheable by clients (and proxies) and means if you ever create a new page with the same path segment it might not be accessible to some.

@mficzel
Copy link
Member Author

mficzel commented Apr 4, 2019

In that case we should remove the feature or disable by default

@gerhard-boden
Copy link
Contributor

I always deactivated this status code via configuration on my installations (so I know it worked at some point). Maybe it went away (pun intended) during the last rewrite. Nobody else seems to have noticed, but we should mention the change in behaviour since 3.0

@gerhard-boden
Copy link
Contributor

gerhard-boden commented Apr 4, 2019

trick question: Is it a breaking change when you remove / disable a broken feature 🤔 ?

@mficzel
Copy link
Member Author

mficzel commented Apr 7, 2019

Not breaking, it is more a clarification to the docs.

@kdambekalns
Copy link
Member

Good URLs don't change and all that… But I still think 410 has value, and is better than a 404 if something is gone… at least you know you are looking in the right place and can stop looking further.

🤷‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants