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.

Sign up for GitHub

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

Jump to bottom

Remove same-port https/http handling behavior #10181

Closed
epixa opened this issue Feb 3, 2017 · 1 comment
Closed

Remove same-port https/http handling behavior #10181

epixa opened this issue Feb 3, 2017 · 1 comment
Assignees
@kimjoar
Labels
release_note:breaking Team:Operations Team label for Operations Team v6.0.0

Comments

@epixa
Copy link
Contributor

epixa commented Feb 3, 2017

Handling http and https requests on the same port is really hacky and prone to unexpected bugs in various different setups. We should remove this capability entirely and introduce an alternative approach to http -> https redirection.
@epixa epixa added Team:Operations Team label for Operations Team release_note:breaking v6.0.0 labels Feb 3, 2017
@spalger spalger mentioned this issue Feb 3, 2017
Closed
@uboness
Copy link

uboness commented Feb 7, 2017

+100 yes please!

@jbudz jbudz mentioned this issue Mar 29, 2017
Merged
@tylersmalley tylersmalley mentioned this issue Mar 29, 2017
Closed
@kimjoar kimjoar self-assigned this Jul 6, 2017
@tabarra tabarra mentioned this issue Aug 14, 2019
Closed
e40pud added a commit to e40pud/kibana that referenced this issue Aug 8, 2024
@e40pud
[Detections] EQL query validation: Separate syntax errors into a own …
b11642e 
…error type (elastic#10181)
e40pud added a commit that referenced this issue Aug 15, 2024
@e40pud @elasticmachine
[Detections] EQL query validation: Separate syntax errors into a own …
2c5ae36 
…error type (#10181) (#190149)

## Summary

Addresses elastic/security-team#10181

This PR is a refactoring of EQL query validator:
* to separate different validation errors passed from ES. Before we
marked `parsing_exception`, `verification_exception` and
`mapping_exception` as the same error of type `ERR_INVALID_EQL`. After
these changes we will split these errors into separate ones: syntax
(`parsing_exception`), invalid EQL (`verification_exception` and
`mapping_exception`; can be split in future if needed)
* to handle missing data source as a new EQL error of type
`MISSING_DATA_SOURCE`. Before
`data.search.search<EqlSearchStrategyRequest,
EqlSearchStrategyResponse>()` call would throw an exception in case data
source does not exist and we would handle it as a failed request and
show an error toast (see relevant ticket
#178611). After these changes we
would not show a toast and handle missing data source error as other EQL
validation errors - showing an error message in the EQL query bar.

This will allow us to distinguish between different types of EQL
validation errors and will help to decide on whether certain errors are
blocking during the rule creation/editing flow
(#180407).

### Checklist

Delete any items that are not applicable to this PR.

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [Integration: Rule
execution](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6754)
(100 ESS & 100 Serverless)
- [Cypress: Detection
Engine](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6766)
(100 ESS & 100 Serverless)

---------

Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kimjoar kimjoar

Labels
release_note:breaking Team:Operations Team label for Operations Team v6.0.0
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kimjoar @epixa @uboness