ext_authz ignores uri with http_service

Issue/Bug Template
Title: I can't make ext_authz work
Description:

ext_authz config seems to ignore uri parameter. Request goes straight to the auth_cluster cluster right onto the cluster's host and port rewriting the path.

Repro steps:

Config set as lower. Running two light python servers on 5001 and 5000. One with endpoint /verify and second with endpoint /dupa. Going into the browser and typing http://<IP_ADDRESS>/dupa.

Admin and Stats Output:

Include the admin output for the following endpoints: /stats,

cluster.auth_cluster.bind_errors: 0
cluster.auth_cluster.circuit_breakers.default.cx_open: 0
cluster.auth_cluster.circuit_breakers.default.rq_open: 0
cluster.auth_cluster.circuit_breakers.default.rq_pending_open: 0
cluster.auth_cluster.circuit_breakers.default.rq_retry_open: 0
cluster.auth_cluster.circuit_breakers.high.cx_open: 0
cluster.auth_cluster.circuit_breakers.high.rq_open: 0
cluster.auth_cluster.circuit_breakers.high.rq_pending_open: 0
cluster.auth_cluster.circuit_breakers.high.rq_retry_open: 0
cluster.auth_cluster.internal.upstream_rq_404: 1
cluster.auth_cluster.internal.upstream_rq_4xx: 1
cluster.auth_cluster.internal.upstream_rq_completed: 1
cluster.auth_cluster.lb_healthy_panic: 0
cluster.auth_cluster.lb_local_cluster_not_ok: 0
cluster.auth_cluster.lb_recalculate_zone_structures: 0
cluster.auth_cluster.lb_subsets_active: 0
cluster.auth_cluster.lb_subsets_created: 0
cluster.auth_cluster.lb_subsets_fallback: 0
cluster.auth_cluster.lb_subsets_removed: 0
cluster.auth_cluster.lb_subsets_selected: 0
cluster.auth_cluster.lb_zone_cluster_too_small: 0
cluster.auth_cluster.lb_zone_no_capacity_left: 0
cluster.auth_cluster.lb_zone_number_differs: 0
cluster.auth_cluster.lb_zone_routing_all_directly: 0
cluster.auth_cluster.lb_zone_routing_cross_zone: 0
cluster.auth_cluster.lb_zone_routing_sampled: 0
cluster.auth_cluster.max_host_weight: 0
cluster.auth_cluster.membership_change: 1
cluster.auth_cluster.membership_healthy: 1
cluster.auth_cluster.membership_total: 1
cluster.auth_cluster.original_dst_host_invalid: 0
cluster.auth_cluster.retry_or_shadow_abandoned: 0
cluster.auth_cluster.update_attempt: 6
cluster.auth_cluster.update_empty: 0
cluster.auth_cluster.update_failure: 0
cluster.auth_cluster.update_no_rebuild: 0
cluster.auth_cluster.update_success: 6
cluster.auth_cluster.upstream_cx_active: 0
cluster.auth_cluster.upstream_cx_close_notify: 0
cluster.auth_cluster.upstream_cx_connect_attempts_exceeded: 0
cluster.auth_cluster.upstream_cx_connect_fail: 0
cluster.auth_cluster.upstream_cx_connect_timeout: 0
cluster.auth_cluster.upstream_cx_destroy: 0
cluster.auth_cluster.upstream_cx_destroy_local: 0
cluster.auth_cluster.upstream_cx_destroy_local_with_active_rq: 0
cluster.auth_cluster.upstream_cx_destroy_remote: 0
cluster.auth_cluster.upstream_cx_destroy_remote_with_active_rq: 0
cluster.auth_cluster.upstream_cx_destroy_with_active_rq: 0
cluster.auth_cluster.upstream_cx_http1_total: 1
cluster.auth_cluster.upstream_cx_http2_total: 0
cluster.auth_cluster.upstream_cx_idle_timeout: 0
cluster.auth_cluster.upstream_cx_max_requests: 0
cluster.auth_cluster.upstream_cx_none_healthy: 0
cluster.auth_cluster.upstream_cx_overflow: 0
cluster.auth_cluster.upstream_cx_protocol_error: 0
cluster.auth_cluster.upstream_cx_rx_bytes_buffered: 0
cluster.auth_cluster.upstream_cx_rx_bytes_total: 380
cluster.auth_cluster.upstream_cx_total: 1
cluster.auth_cluster.upstream_cx_tx_bytes_buffered: 0
cluster.auth_cluster.upstream_cx_tx_bytes_total: 155
cluster.auth_cluster.upstream_flow_control_backed_up_total: 0
cluster.auth_cluster.upstream_flow_control_drained_total: 0
cluster.auth_cluster.upstream_flow_control_paused_reading_total: 0
cluster.auth_cluster.upstream_flow_control_resumed_reading_total: 0
cluster.auth_cluster.upstream_rq_404: 1
cluster.auth_cluster.upstream_rq_4xx: 1
cluster.auth_cluster.upstream_rq_active: 0
cluster.auth_cluster.upstream_rq_cancelled: 0
cluster.auth_cluster.upstream_rq_completed: 1
cluster.auth_cluster.upstream_rq_maintenance_mode: 0
cluster.auth_cluster.upstream_rq_pending_active: 0
cluster.auth_cluster.upstream_rq_pending_failure_eject: 0
cluster.auth_cluster.upstream_rq_pending_overflow: 0
cluster.auth_cluster.upstream_rq_pending_total: 1
cluster.auth_cluster.upstream_rq_per_try_timeout: 0
cluster.auth_cluster.upstream_rq_retry: 0
cluster.auth_cluster.upstream_rq_retry_overflow: 0
cluster.auth_cluster.upstream_rq_retry_success: 0
cluster.auth_cluster.upstream_rq_rx_reset: 0
cluster.auth_cluster.upstream_rq_timeout: 0
cluster.auth_cluster.upstream_rq_total: 1
cluster.auth_cluster.upstream_rq_tx_reset: 0
cluster.auth_cluster.version: 0
cluster.local_backend.bind_errors: 0
cluster.local_backend.circuit_breakers.default.cx_open: 0
cluster.local_backend.circuit_breakers.default.rq_open: 0
cluster.local_backend.circuit_breakers.default.rq_pending_open: 0
cluster.local_backend.circuit_breakers.default.rq_retry_open: 0
cluster.local_backend.circuit_breakers.high.cx_open: 0
cluster.local_backend.circuit_breakers.high.rq_open: 0
cluster.local_backend.circuit_breakers.high.rq_pending_open: 0
cluster.local_backend.circuit_breakers.high.rq_retry_open: 0
cluster.local_backend.ext_authz.denied: 1
cluster.local_backend.internal.upstream_rq_404: 1
cluster.local_backend.internal.upstream_rq_4xx: 1
cluster.local_backend.internal.upstream_rq_completed: 1
cluster.local_backend.lb_healthy_panic: 0
cluster.local_backend.lb_local_cluster_not_ok: 0
cluster.local_backend.lb_recalculate_zone_structures: 0
cluster.local_backend.lb_subsets_active: 0
cluster.local_backend.lb_subsets_created: 0
cluster.local_backend.lb_subsets_fallback: 0
cluster.local_backend.lb_subsets_removed: 0
cluster.local_backend.lb_subsets_selected: 0
cluster.local_backend.lb_zone_cluster_too_small: 0
cluster.local_backend.lb_zone_no_capacity_left: 0
cluster.local_backend.lb_zone_number_differs: 0
cluster.local_backend.lb_zone_routing_all_directly: 0
cluster.local_backend.lb_zone_routing_cross_zone: 0
cluster.local_backend.lb_zone_routing_sampled: 0
cluster.local_backend.max_host_weight: 0
cluster.local_backend.membership_change: 1
cluster.local_backend.membership_healthy: 1
cluster.local_backend.membership_total: 1
cluster.local_backend.original_dst_host_invalid: 0
cluster.local_backend.retry_or_shadow_abandoned: 0
cluster.local_backend.update_attempt: 6
cluster.local_backend.update_empty: 0
cluster.local_backend.update_failure: 0
cluster.local_backend.update_no_rebuild: 0
cluster.local_backend.update_success: 6
cluster.local_backend.upstream_cx_active: 0
cluster.local_backend.upstream_cx_close_notify: 0
cluster.local_backend.upstream_cx_connect_attempts_exceeded: 0
cluster.local_backend.upstream_cx_connect_fail: 0
cluster.local_backend.upstream_cx_connect_timeout: 0
cluster.local_backend.upstream_cx_destroy: 0
cluster.local_backend.upstream_cx_destroy_local: 0
cluster.local_backend.upstream_cx_destroy_local_with_active_rq: 0
cluster.local_backend.upstream_cx_destroy_remote: 0
cluster.local_backend.upstream_cx_destroy_remote_with_active_rq: 0
cluster.local_backend.upstream_cx_destroy_with_active_rq: 0
cluster.local_backend.upstream_cx_http1_total: 0
cluster.local_backend.upstream_cx_http2_total: 0
cluster.local_backend.upstream_cx_idle_timeout: 0
cluster.local_backend.upstream_cx_max_requests: 0
cluster.local_backend.upstream_cx_none_healthy: 0
cluster.local_backend.upstream_cx_overflow: 0
cluster.local_backend.upstream_cx_protocol_error: 0
cluster.local_backend.upstream_cx_rx_bytes_buffered: 0
cluster.local_backend.upstream_cx_rx_bytes_total: 0
cluster.local_backend.upstream_cx_total: 0
cluster.local_backend.upstream_cx_tx_bytes_buffered: 0
cluster.local_backend.upstream_cx_tx_bytes_total: 0
cluster.local_backend.upstream_flow_control_backed_up_total: 0
cluster.local_backend.upstream_flow_control_drained_total: 0
cluster.local_backend.upstream_flow_control_paused_reading_total: 0
cluster.local_backend.upstream_flow_control_resumed_reading_total: 0
cluster.local_backend.upstream_rq_404: 1
cluster.local_backend.upstream_rq_4xx: 1
cluster.local_backend.upstream_rq_active: 0
cluster.local_backend.upstream_rq_cancelled: 0
cluster.local_backend.upstream_rq_completed: 1
cluster.local_backend.upstream_rq_maintenance_mode: 0
cluster.local_backend.upstream_rq_pending_active: 0
cluster.local_backend.upstream_rq_pending_failure_eject: 0
cluster.local_backend.upstream_rq_pending_overflow: 0
cluster.local_backend.upstream_rq_pending_total: 0
cluster.local_backend.upstream_rq_per_try_timeout: 0
cluster.local_backend.upstream_rq_retry: 0
cluster.local_backend.upstream_rq_retry_overflow: 0
cluster.local_backend.upstream_rq_retry_success: 0
cluster.local_backend.upstream_rq_rx_reset: 0
cluster.local_backend.upstream_rq_timeout: 0
cluster.local_backend.upstream_rq_total: 0
cluster.local_backend.upstream_rq_tx_reset: 0
cluster.local_backend.version: 0
cluster_manager.active_clusters: 2
cluster_manager.cluster_added: 2
cluster_manager.cluster_modified: 0
cluster_manager.cluster_removed: 0
cluster_manager.cluster_updated: 0
cluster_manager.cluster_updated_via_merge: 0
cluster_manager.update_merge_cancelled: 0
cluster_manager.update_out_of_merge_window: 0
cluster_manager.warming_clusters: 0
filesystem.flushed_by_timer: 0
filesystem.reopen_failed: 0
filesystem.write_buffered: 0
filesystem.write_completed: 0
filesystem.write_total_buffered: 0
http.admin.downstream_cx_active: 1
http.admin.downstream_cx_delayed_close_timeout: 0
http.admin.downstream_cx_destroy: 0
http.admin.downstream_cx_destroy_active_rq: 0
http.admin.downstream_cx_destroy_local: 0
http.admin.downstream_cx_destroy_local_active_rq: 0
http.admin.downstream_cx_destroy_remote: 0
http.admin.downstream_cx_destroy_remote_active_rq: 0
http.admin.downstream_cx_drain_close: 0
http.admin.downstream_cx_http1_active: 1
http.admin.downstream_cx_http1_total: 1
http.admin.downstream_cx_http2_active: 0
http.admin.downstream_cx_http2_total: 0
http.admin.downstream_cx_idle_timeout: 0
http.admin.downstream_cx_overload_disable_keepalive: 0
http.admin.downstream_cx_protocol_error: 0
http.admin.downstream_cx_rx_bytes_buffered: 423
http.admin.downstream_cx_rx_bytes_total: 423
http.admin.downstream_cx_ssl_active: 0
http.admin.downstream_cx_ssl_total: 0
http.admin.downstream_cx_total: 1
http.admin.downstream_cx_tx_bytes_buffered: 0
http.admin.downstream_cx_tx_bytes_total: 0
http.admin.downstream_cx_upgrades_active: 0
http.admin.downstream_cx_upgrades_total: 0
http.admin.downstream_flow_control_paused_reading_total: 0
http.admin.downstream_flow_control_resumed_reading_total: 0
http.admin.downstream_rq_1xx: 0
http.admin.downstream_rq_2xx: 0
http.admin.downstream_rq_3xx: 0
http.admin.downstream_rq_4xx: 0
http.admin.downstream_rq_5xx: 0
http.admin.downstream_rq_active: 1
http.admin.downstream_rq_completed: 0
http.admin.downstream_rq_http1_total: 1
http.admin.downstream_rq_http2_total: 0
http.admin.downstream_rq_idle_timeout: 0
http.admin.downstream_rq_non_relative_path: 0
http.admin.downstream_rq_overload_close: 0
http.admin.downstream_rq_response_before_rq_complete: 0
http.admin.downstream_rq_rx_reset: 0
http.admin.downstream_rq_timeout: 0
http.admin.downstream_rq_too_large: 0
http.admin.downstream_rq_total: 1
http.admin.downstream_rq_tx_reset: 0
http.admin.downstream_rq_ws_on_non_ws_route: 0
http.admin.rs_too_large: 0
http.async-client.no_cluster: 0
http.async-client.no_route: 0
http.async-client.rq_direct_response: 0
http.async-client.rq_redirect: 0
http.async-client.rq_total: 1
http.ingress_http.downstream_cx_active: 1
http.ingress_http.downstream_cx_delayed_close_timeout: 0
http.ingress_http.downstream_cx_destroy: 0
http.ingress_http.downstream_cx_destroy_active_rq: 0
http.ingress_http.downstream_cx_destroy_local: 0
http.ingress_http.downstream_cx_destroy_local_active_rq: 0
http.ingress_http.downstream_cx_destroy_remote: 0
http.ingress_http.downstream_cx_destroy_remote_active_rq: 0
http.ingress_http.downstream_cx_drain_close: 0
http.ingress_http.downstream_cx_http1_active: 1
http.ingress_http.downstream_cx_http1_total: 1
http.ingress_http.downstream_cx_http2_active: 0
http.ingress_http.downstream_cx_http2_total: 0
http.ingress_http.downstream_cx_idle_timeout: 0
http.ingress_http.downstream_cx_overload_disable_keepalive: 0
http.ingress_http.downstream_cx_protocol_error: 0
http.ingress_http.downstream_cx_rx_bytes_buffered: 448
http.ingress_http.downstream_cx_rx_bytes_total: 448
http.ingress_http.downstream_cx_ssl_active: 0
http.ingress_http.downstream_cx_ssl_total: 0
http.ingress_http.downstream_cx_total: 1
http.ingress_http.downstream_cx_tx_bytes_buffered: 0
http.ingress_http.downstream_cx_tx_bytes_total: 358
http.ingress_http.downstream_cx_upgrades_active: 0
http.ingress_http.downstream_cx_upgrades_total: 0
http.ingress_http.downstream_flow_control_paused_reading_total: 0
http.ingress_http.downstream_flow_control_resumed_reading_total: 0
http.ingress_http.downstream_rq_1xx: 0
http.ingress_http.downstream_rq_2xx: 0
http.ingress_http.downstream_rq_3xx: 0
http.ingress_http.downstream_rq_4xx: 1
http.ingress_http.downstream_rq_5xx: 0
http.ingress_http.downstream_rq_active: 0
http.ingress_http.downstream_rq_completed: 1
http.ingress_http.downstream_rq_http1_total: 1
http.ingress_http.downstream_rq_http2_total: 0
http.ingress_http.downstream_rq_idle_timeout: 0
http.ingress_http.downstream_rq_non_relative_path: 0
http.ingress_http.downstream_rq_overload_close: 0
http.ingress_http.downstream_rq_response_before_rq_complete: 0
http.ingress_http.downstream_rq_rx_reset: 0
http.ingress_http.downstream_rq_timeout: 0
http.ingress_http.downstream_rq_too_large: 0
http.ingress_http.downstream_rq_total: 1
http.ingress_http.downstream_rq_tx_reset: 0
http.ingress_http.downstream_rq_ws_on_non_ws_route: 0
http.ingress_http.no_cluster: 0
http.ingress_http.no_route: 0
http.ingress_http.rq_direct_response: 0
http.ingress_http.rq_redirect: 0
http.ingress_http.rq_total: 0
http.ingress_http.rs_too_large: 0
http.ingress_http.tracing.client_enabled: 0
http.ingress_http.tracing.health_check: 0
http.ingress_http.tracing.not_traceable: 0
http.ingress_http.tracing.random_sampling: 0
http.ingress_http.tracing.service_forced: 0
listener.<IP_ADDRESS>_8080.downstream_cx_active: 1
listener.<IP_ADDRESS>_8080.downstream_cx_destroy: 0
listener.<IP_ADDRESS>_8080.downstream_cx_total: 1
listener.<IP_ADDRESS>_8080.downstream_pre_cx_active: 0
listener.<IP_ADDRESS>_8080.downstream_pre_cx_timeout: 0
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_1xx: 0
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_2xx: 0
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_3xx: 0
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_4xx: 1
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_5xx: 0
listener.<IP_ADDRESS>_8080.http.ingress_http.downstream_rq_completed: 1
listener.<IP_ADDRESS>_8080.no_filter_chain_match: 0
listener.admin.downstream_cx_active: 1
listener.admin.downstream_cx_destroy: 0
listener.admin.downstream_cx_total: 1
listener.admin.downstream_pre_cx_active: 0
listener.admin.downstream_pre_cx_timeout: 0
listener.admin.http.admin.downstream_rq_1xx: 0
listener.admin.http.admin.downstream_rq_2xx: 0
listener.admin.http.admin.downstream_rq_3xx: 0
listener.admin.http.admin.downstream_rq_4xx: 0
listener.admin.http.admin.downstream_rq_5xx: 0
listener.admin.http.admin.downstream_rq_completed: 0
listener.admin.no_filter_chain_match: 0
listener_manager.listener_added: 1
listener_manager.listener_create_failure: 0
listener_manager.listener_create_success: 8
listener_manager.listener_modified: 0
listener_manager.listener_removed: 0
listener_manager.total_listeners_active: 1
listener_manager.total_listeners_draining: 0
listener_manager.total_listeners_warming: 0
runtime.admin_overrides_active: 0
runtime.load_error: 0
runtime.load_success: 0
runtime.num_keys: 0
runtime.override_dir_exists: 0
runtime.override_dir_not_exists: 0
server.concurrency: 8
server.days_until_first_cert_expiring:<PHONE_NUMBER>
server.hot_restart_epoch: 0
server.live: 1
server.memory_allocated: 3608808
server.memory_heap_size: 5242880
server.parent_connections: 0
server.total_connections: 1
server.uptime: 25
server.version: 1997534
server.watchdog_mega_miss: 0
server.watchdog_miss: 0
stats.overflow: 0
cluster.auth_cluster.internal.upstream_rq_time: P0(nan,1) P25(nan,1.025) P50(nan,1.05) P75(nan,1.075) P90(nan,1.09) P95(nan,1.095) P99(nan,1.099) P99.5(nan,1.0995) P99.9(nan,1.0999) P100(nan,1.1)
cluster.auth_cluster.upstream_cx_connect_ms: P0(nan,0) P25(nan,0) P50(nan,0) P75(nan,0) P90(nan,0) P95(nan,0) P99(nan,0) P99.5(nan,0) P99.9(nan,0) P100(nan,0)
cluster.auth_cluster.upstream_cx_length_ms: P0(nan,1) P25(nan,1.025) P50(nan,1.05) P75(nan,1.075) P90(nan,1.09) P95(nan,1.095) P99(nan,1.099) P99.5(nan,1.0995) P99.9(nan,1.0999) P100(nan,1.1)
cluster.auth_cluster.upstream_rq_time: P0(nan,1) P25(nan,1.025) P50(nan,1.05) P75(nan,1.075) P90(nan,1.09) P95(nan,1.095) P99(nan,1.099) P99.5(nan,1.0995) P99.9(nan,1.0999) P100(nan,1.1)
cluster.local_backend.upstream_cx_connect_ms: No recorded values
cluster.local_backend.upstream_cx_length_ms: No recorded values
http.admin.downstream_cx_length_ms: No recorded values
http.admin.downstream_rq_time: No recorded values
http.ingress_http.downstream_cx_length_ms: No recorded values
http.ingress_http.downstream_rq_time: P0(nan,3) P25(nan,3.025) P50(nan,3.05) P75(nan,3.075) P90(nan,3.09) P95(nan,3.095) P99(nan,3.099) P99.5(nan,3.0995) P99.9(nan,3.0999) P100(nan,3.1)
listener.<IP_ADDRESS>_8080.downstream_cx_length_ms: No recorded values
listener.admin.downstream_cx_length_ms: No recorded values

/clusters,
local_backend::default_priority::max_connections::1024
local_backend::default_priority::max_pending_requests::1024
local_backend::default_priority::max_requests::1024
local_backend::default_priority::max_retries::3
local_backend::high_priority::max_connections::1024
local_backend::high_priority::max_pending_requests::1024
local_backend::high_priority::max_requests::1024
local_backend::high_priority::max_retries::3
local_backend::added_via_api::false
local_backend::<IP_ADDRESS>:0::cx_active::0
local_backend::<IP_ADDRESS>:0::cx_connect_fail::0
local_backend::<IP_ADDRESS>:0::cx_total::0
local_backend::<IP_ADDRESS>:0::rq_active::0
local_backend::<IP_ADDRESS>:0::rq_error::0
local_backend::<IP_ADDRESS>:0::rq_success::0
local_backend::<IP_ADDRESS>:0::rq_timeout::0
local_backend::<IP_ADDRESS>:0::rq_total::0
local_backend::<IP_ADDRESS>:0::health_flags::healthy
local_backend::<IP_ADDRESS>:0::weight::1
local_backend::<IP_ADDRESS>:0::region::
local_backend::<IP_ADDRESS>:0::zone::
local_backend::<IP_ADDRESS>:0::sub_zone::
local_backend::<IP_ADDRESS>:0::canary::false
local_backend::<IP_ADDRESS>:0::success_rate::-1
auth_cluster::default_priority::max_connections::1024
auth_cluster::default_priority::max_pending_requests::1024
auth_cluster::default_priority::max_requests::1024
auth_cluster::default_priority::max_retries::3
auth_cluster::high_priority::max_connections::1024
auth_cluster::high_priority::max_pending_requests::1024
auth_cluster::high_priority::max_requests::1024
auth_cluster::high_priority::max_retries::3
auth_cluster::added_via_api::false
auth_cluster::<IP_ADDRESS>:0::cx_active::0
auth_cluster::<IP_ADDRESS>:0::cx_connect_fail::0
auth_cluster::<IP_ADDRESS>:0::cx_total::1
auth_cluster::<IP_ADDRESS>:0::rq_active::0
auth_cluster::<IP_ADDRESS>:0::rq_error::0
auth_cluster::<IP_ADDRESS>:0::rq_success::1
auth_cluster::<IP_ADDRESS>:0::rq_timeout::0
auth_cluster::<IP_ADDRESS>:0::rq_total::1
auth_cluster::<IP_ADDRESS>:0::health_flags::healthy
auth_cluster::<IP_ADDRESS>:0::weight::1
auth_cluster::<IP_ADDRESS>:0::region::
auth_cluster::<IP_ADDRESS>:0::zone::
auth_cluster::<IP_ADDRESS>:0::sub_zone::
auth_cluster::<IP_ADDRESS>:0::canary::false
auth_cluster::<IP_ADDRESS>:0::success_rate::-1

/routes,
nope

/server_info
{
 "version": "1e7adefe27951f13e2be141ce91a29727bdafd8b/1.9.0-dev/Clean/RELEASE",
 "state": "LIVE",
 "command_line_options": {
  "base_id": "0",
  "concurrency": 8,
  "config_path": "envoy.yaml",
  "config_yaml": "",
  "allow_unknown_fields": false,
  "admin_address_path": "",
  "local_address_ip_version": "v4",
  "log_level": "debug",
  "component_log_level": "",
  "log_format": "[%Y-%m-%d %T.%e][%t][%l][%n] %v",
  "log_path": "",
  "hot_restart_version": false,
  "service_cluster": "",
  "service_node": "",
  "service_zone": "",
  "mode": "Serve",
  "max_stats": "16384",
  "max_obj_name_len": "60",
  "disable_hot_restart": false,
  "enable_mutex_tracing": false,
  "restart_epoch": 0,
  "file_flush_interval": "10s",
  "drain_time": "600s",
  "parent_shutdown_time": "900s"
 },
 "uptime_current_epoch": "321s",
 "uptime_all_epochs": "321s"
}

Config:
static_resources:
  listeners:
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 8080
        protocol: TCP
    filter_chains:
      filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            response_headers_to_remove: "TEST-HEADER"
            virtual_hosts:
            - name: backend_virtual_host
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_backend
          http_filters:
          - name: envoy.ext_authz
            config:
              http_service:
                server_uri:
                  uri: "http://<IP_ADDRESS>:5001/verify"
                  cluster: auth_cluster
                  timeout: 0.1s
          - name: envoy.router
            config: {}

  clusters:
  - name: local_backend
    connect_timeout: 0.25s
    type: logical_dns
    lb_policy: round_robin
    hosts:
    - socket_address:
        address: <IP_ADDRESS>
        port_value: 5000
  - name: auth_cluster
    connect_timeout: 0.1s
    type: logical_dns
    lb_policy: round_robin
    hosts:
    - socket_address:
        address: <IP_ADDRESS>
        port_value: 5001

admin:
  access_log_path: "/dev/stdout"
  address:
    socket_address:
      address: <IP_ADDRESS>
      port_value: 8012

Logs:

[2018-12-20 00:41:02.962][004762][debug][main] [source/server/connection_handler_impl.cc:256] [C0] new connection
[2018-12-20 00:41:02.962][004762][debug][http] [source/common/http/conn_manager_impl.cc:200] [C0] new stream
[2018-12-20 00:41:02.964][004762][debug][http] [source/common/http/conn_manager_impl.cc:537] [C0][S3933711892607205960] request headers complete (end_stream=true):
':authority', '<IP_ADDRESS>:8080'
':path', '/dupa'
':method', 'GET'
'connection', 'keep-alive'
'cache-control', 'max-age=0'
'upgrade-insecure-requests', '1'
'user-agent', 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.103 Safari/537.36 Vivaldi/2.1.1337.47'
'accept', 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8'
'accept-encoding', 'gzip, deflate, br'
'accept-language', 'pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7'
[2018-12-20 00:41:02.964][004762][debug][http] [source/common/http/conn_manager_impl.cc:953] [C0][S3933711892607205960] request end stream
[2018-12-20 00:41:02.965][004762][debug][router] [source/common/router/router.cc:265] [C0][S13096545413718075315] cluster 'auth_cluster' match for URL '/dupa'
[2018-12-20 00:41:02.965][004762][debug][router] [source/common/router/router.cc:323] [C0][S13096545413718075315] router decoding headers:
':path', '/dupa'
':authority', '<IP_ADDRESS>:8080'
':method', 'GET'
':scheme', 'http'
'content-length', '0'
'x-envoy-internal', 'true'
'x-forwarded-for', '<IP_ADDRESS>'
'x-envoy-expected-rq-timeout-ms', '100'
[2018-12-20 00:41:02.965][004762][debug][pool] [source/common/http/http1/conn_pool.cc:80] creating a new connection
[2018-12-20 00:41:02.965][004762][debug][client] [source/common/http/codec_client.cc:26] [C1] connecting
[2018-12-20 00:41:02.965][004762][debug][connection] [source/common/network/connection_impl.cc:634] [C1] connecting to <IP_ADDRESS>:5001
[2018-12-20 00:41:02.965][004762][debug][connection] [source/common/network/connection_impl.cc:643] [C1] connection in progress
[2018-12-20 00:41:02.965][004762][debug][pool] [source/common/http/conn_pool_base.cc:20] queueing request due to no available connections
[2018-12-20 00:41:02.965][004762][debug][connection] [source/common/network/connection_impl.cc:516] [C1] connected
[2018-12-20 00:41:02.965][004762][debug][client] [source/common/http/codec_client.cc:64] [C1] connected
[2018-12-20 00:41:02.965][004762][debug][pool] [source/common/http/http1/conn_pool.cc:234] [C1] attaching to next request
[2018-12-20 00:41:02.965][004762][debug][router] [source/common/router/router.cc:1018] [C0][S13096545413718075315] pool ready
[2018-12-20 00:41:02.967][004762][debug][router] [source/common/router/router.cc:610] [C0][S13096545413718075315] upstream headers complete: end_stream=false
[2018-12-20 00:41:02.967][004762][debug][http] [source/common/http/async_client_impl.cc:93] async http request response headers (end_stream=false):
':status', '404'
'content-type', 'text/html'
'content-length', '233'
'server', 'Werkzeug/0.14.1 Python/3.6.7'
'date', 'Wed, 19 Dec 2018 23:41:02 GMT'
'x-envoy-upstream-service-time', '1'
[2018-12-20 00:41:02.967][004762][debug][client] [source/common/http/codec_client.cc:95] [C1] response complete
[2018-12-20 00:41:02.967][004762][debug][filter] [source/extensions/filters/http/ext_authz/ext_authz.cc:134] [C0][S3933711892607205960] ext_authz rejected the request
[2018-12-20 00:41:02.967][004762][debug][http] [source/common/http/conn_manager_impl.cc:1188] [C0][S3933711892607205960] encoding headers via codec (end_stream=false):
':status', '404'
'content-length', '233'
'content-type', 'text/plain'
'date', 'Wed, 19 Dec 2018 23:41:02 GMT'
'server', 'envoy'
[2018-12-20 00:41:02.968][004762][debug][pool] [source/common/http/http1/conn_pool.cc:191] [C1] response complete
[2018-12-20 00:41:02.968][004762][debug][pool] [source/common/http/http1/conn_pool.cc:229] [C1] moving to ready
[2018-12-20 00:41:02.968][004762][debug][connection] [source/common/network/connection_impl.cc:501] [C1] remote close
[2018-12-20 00:41:02.968][004762][debug][connection] [source/common/network/connection_impl.cc:183] [C1] closing socket: 0
[2018-12-20 00:41:02.968][004762][debug][client] [source/common/http/codec_client.cc:82] [C1] disconnect. resetting 0 pending requests
[2018-12-20 00:41:02.968][004762][debug][pool] [source/common/http/http1/conn_pool.cc:121] [C1] client disconnected
[2018-12-20 00:41:07.770][004743][debug][main] [source/server/server.cc:143] flushing stats

@gsagula

Hi, thanks for quick response!
Why it's not right?
I've already tried path_prefix. It prepended the /dupa with /verify/, so the path looked like /verify/dupa.
The endpoint like this does not exist.

@gsagula Maybe I'll describe what I would like to achieve.
I want every request hitting http://localhost:8080 (no matter what endpoint) to be sent to http://localhost:5001/verify in order to be verified. There I need to check for some headers and if it is ok, forward it to the endpoint it originally requested. Otherwise - reject. Maybe I don't get how this filter should work but it seems to me, that request should be fully sent to the specified URI which is in the bounds of the specified cluster.

@dawid-manikowski I think what you want is to set uri: "http://<IP_ADDRESS>:5001" and path_prefix: "/verify" . This should definitely send every single request to the auth_cluster. Make sure that auth_cluster has the correct endpoint.

@gsagula Already did that. The problem is that the request path is being appended to the prefix. So I should prepare lots of endpoints on auth_cluster. Any way around it? Thanks in advance and best wishes in the New Year :)

Is there no solution to this with http_service since then? If not, can you give an example grpc configuration please?

The same thing is happening to me too. But for me, unfortunately, I can't use GRPC server.

@rocks4530 We're still trying things out, but as a quick hack I overridden the ext_authz_http_impl to do the modifications I needed. It was pretty straightforward. Check out RawHttpClientImpl::check(...) and ClientConfig::ClientConfig i you need to add anything. I am not sure what's your exact scenario but I can show you if you'd like.

@sekaninat let me explain what we need exactly
I want every request hitting http://localhost:8080 (no matter what endpoint) to be sent to http://localhost:5001/verify in order to be verified/authorized. There I need to check for some headers and if it is ok, forward it to the endpoint it originally requested. Otherwise - reject. Currently whatever we put in
server_uri:
uri: http://localhost:5001/verify. It doesn't take. Hope you got my point.

I think there is already a similar issue @https://github.com/envoyproxy/envoy/issues/6099. Just FYI

@sekaninat, mind to open a PR? I'd like to help to review if needed. Thank you!

@rocks4530 Yeah that's pretty much the same scenario I had.
And exactly as discussed in the other issue. That's pretty wrong imho to have parameter that doesn't do anything.
@dio I'll see what I can do, I should probably make it bit nicer as I just overridden the original code :blush:. For now here a diff https://pastebin.com/8MLjZDpR

@sekaninat thanks! Please let us know!

@sekaninat any update on this?

@rocks4530 Slowly getting to it...

@rocks4530 Sorry, we need to get it running at least in the form I have right now, so there are few things I have to tackle first, but it is pretty high on my priorities. (I forked it already though :sunglasses: :laughing:.)
@dio But I am starting to wonder what's the correct approach here... Adding another mutually exclusive option to grpc_service and http_service (docs), which would change just some stuff and otherwise copy the http_service? I guess the server_uri would be omitted and taken from the cluster config + path_prefix. And it would be actually applied to the request :laughing:.

@jcr010910 the proposed solution may be working.
But we will love to see the original issue to be fixed.

This issue still exists!! server_uri in http_service is like a parameter which is dummy, but the document says it's required.

any updates on this?

@rahul-gupta-1525 I have a WIP here: https://github.com/envoyproxy/envoy/pull/10573. Need to update the URL lib to use the newly imported googleurl.

Looking into this now.
I think one desirable characteristic of HTTP ExternalAuthorization is being able to send the data to a single endpoint, e.g. POST /authenticate similarly to how the gRPC implementation calls a single RPC. The current implementation expects the authentication endpoint to accept arbitrary methods/paths because it essentially duplicates the request but targeted to the defined ext-authz cluster, meaning the ext-authz cluster has to support all the endpoints that the upstream would receive. For my use-case (and seemingly others in this thread) this is not desirable.
I propose we evolve the API to allow users to opt-in to the ExternalAuthorization filter sending a POST request with certain (configurable) request headers sent in the body, by default including:

host/authority
path
HTTP method
authorization

(this is very similar to authorization_request.allowed_headers but I don't think that name quite fits this usage)
The uri parameter doesn't seem to be referenced anywhere in code. I think specifying the cluster is good (integrating with CDS, able to health check, circuit break, EDS, etc.). I propose we deprecate uri and have users specify authority and path in config.
http_filters:
  - name: envoy.filters.http.ext_authz
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
      http_service:
        server_uri:
          authority: foobar.com
          path: /api/authz
          cluster: ext-authz
          timeout: 0.25s

(we can't use authorization_request.headers_to_add because HeaderParser errors with :-prefixed or host headers may not be modified here:
https://github.com/envoyproxy/envoy/blob/110aec2b2fb61c8c9d3e7295b08beb8d46cc01e3/source/common/router/header_parser.cc#L45-L54
and it's probably not worth trying to inject an exception). This will soon be a need for me, I can start on it this week if agreed upon.
Thoughts @dio @esmet @gsagula ?

Thinking more, would you agree the issue is that most people want the control and semantics of the gRPC authorization server, but may not (for whatever reason) be able to use gRPC?
If that's the case, I think it would be neat to do something like https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/grpc_http1_reverse_bridge_filter#config-http-filters-grpc-http1-reverse-bridge. We'd then be able to tell the async grpc client that ext authz uses to send H1 requests instead of gRPC requests, and the code that generates the body etc could be shared. This would allow us to have a consistent semantic experience but make the transport configurable, which I think is a win. This is the general idea, anyway.

That's a great idea! My basic flow of what I went through was

hmm can I use gRPC? nope
ok let me implement the HTTP endpoint
oh wait it doesn't work that way

So I think consistency between the gRPC and HTTP implementations would be great. I'll need to read a bit of code to better figure out how the grpc-http1-reverse-bridge fits in code-wise, but another alternative implementation could be

populate the envoy::service::auth::v3::CheckRequest message, same as gRPC impl
use protobuf's JSON-encoding to turn it into a POST request
dispatch the async http request

It would still allow quite a bit of code-reuse between the two, and depending on what I find might be simpler than pulling in a reverse-bridge.
I think regardless, we'd still need to allow a configurable path? I'm not super familiar with the reverse bridge but I'm imagining it'll set the path to the gRPC method, do we want to be that prescriptive?

Right, something like encoding a CheckRequest as JSON and sending it via HTTP 1 is the right idea.
I think code reuse and moving towards a consistent user experience are my biggest goals. Do you also have a proposed filter config / API in mind?

I'm also suffering from a related issue with the Host/Authority header, now that it's no longer allowed to override the Host header (for reference, this is the config I use in 1.17.x):
headers_to_add:
  key: "host"
  value: "authserver.net"

Unfortunately our auth server relies on a vhost style routing setup; we're unable to upgrade to 1.18.x as there appears to be no way to use the host from the 'uri' field or any other way to specify it, instead we're forced to use the host value from the original request.
I very much like @derekargueta suggestion of allowing the authority and path to be specified directly.

Hi,
I am attempting to make below call to elasticsearch via envoy reverse proxy
$ curl https://mydomain:1900/_search/_cat/indices/myindex* -H "<CUSTOMER_HEADER>:<TOKEN_ACCEPTED_BY_AUTHSERVER>" -v
envoy.yaml
`admin:
address:
socket_address: { address: <IP_ADDRESS>, port_value: 9901 }
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: <IP_ADDRESS>, port_value: 10000 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
codec_type: AUTO
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /dev/stdout
log_format:
text_format: "[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-USER-ID)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%REQ(X-ENVOY-EXTERNAL-ADDRESS)%"\n"
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: [ "*" ]
routes:
- match:
prefix: "/_search/"
route:
prefix_rewrite: "/"
cluster: elasticsearch
http_filters:
- name: envoy.filters.http.ext_authz
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
clear_route_cache: true
transport_api_version: V3
http_service:
server_uri:
uri: auth_server:5000
cluster: ext-authz
timeout: 2s
path_prefix: /verify
authorization_request:
allowed_headers:
patterns:
- contains: "[CUSTOMER_HEADER_TO_BE_SENT_TO_AUTHSERVER]"
- name: envoy.filters.http.router
clusters:
- name: elasticsearch
connect_timeout: 0.25s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: elasticsearch
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: ${ELASTICSEARCH_URL}
port_value: 9200
- name: ext-authz
  connect_timeout: 0.25s
  type: STRICT_DNS
  lb_policy: ROUND_ROBIN
  load_assignment:
    cluster_name: ext-authz
    endpoints:
      - lb_endpoints:
          - endpoint:
              address:
                socket_address:
                  address: auth_server
                  port_value: 5000

`
envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':authority', 'front-envoy:10000' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':path', '/_cat/indices/envoyindex*' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':method', 'GET' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'user-agent', 'curl/7.64.1' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'accept', '*/*' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'customer-header', 'xxxxx' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-webauth-user', '' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-opaque-id', '' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'authorization', 'Basic xxxx==' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-forwarded-for', '<IP_ADDRESS>' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-forwarded-host', 'mydomain.com:11764' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-forwarded-server', 'mydomain.com' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'connection', 'close' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | [2021-07-26 14:02:42.340][15][debug][http] [source/common/http/filter_manager.cc:808] [C0][S14087186086586968795] request end stream envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | [2021-07-26 14:02:42.340][15][debug][router] [source/common/router/router.cc:448] [C0][S17215580684348599812] cluster 'ext-authz' match for URL '/verify/_cat/indices/envoyindex*' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | [2021-07-26 14:02:42.342][15][debug][router] [source/common/router/router.cc:634] [C0][S17215580684348599812] router decoding headers: envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':method', 'GET' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':path', '/verify/_cat/indices/envoyindex*' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':authority', 'front-envoy:10000' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | ':scheme', 'http' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'content-length', '0' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'authorization', 'Basic xxx==' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-envoy-internal', 'true' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-forwarded-for', '10.s.ss.ss' envoyindex_front-envoy.1.jxi03i6vy9r2@ip-10-xx-xx-xx    | 'x-envoy-expected-rq-timeout-ms', '2000'
The request URI seems to be /verify/cat/indices/envoyindex instead of /verify forwarded to Auth Server. What config changes needs to be done to get this right?

Hi Team,
I have been able to configure ext_authz with http_service
admin:
  address:
    socket_address: { address: <IP_ADDRESS>, port_value: 8000 }

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address: { address: <IP_ADDRESS>, port_value: 9000 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: AUTO
                access_log:
                - name: envoy.access_loggers.file
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                    path: /dev/stdout
                    log_format:
                      text_format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE%  %RESPONSE_CODE_DETAILS% %RESPONSE_FLAGS% %CONNECTION_TERMINATION_DETAILS% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-USER-ID)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" \"%REQ(X-ENVOY-EXTERNAL-ADDRESS)%\"\n"
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: [ "*" ]
                      routes:
                        - match: { prefix: "/_search" }
                          route:
                            prefix_rewrite: "/"
                            cluster: ES

                http_filters:
                  - name: envoy.filters.http.ext_authz
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
                      clear_route_cache: true
                      transport_api_version: V3
                      http_service:
                        server_uri:
                          uri: auth_server:1001
                          cluster: ext-authz
                          timeout: 2s
                        path_prefix: /verifyme
                        authorization_request:
                          allowed_headers:
                            patterns:
                              - exact: "[my-customer-header]"
                  - name: envoy.filters.http.router

  clusters:
    - name: ext-authz
      connect_timeout: 0.25s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: ext-authz
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address:  auth_server
                      port_value: 1001
    - name: ES
      connect_timeout: 0.25s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: ES
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: {es-container-ip}
                      port_value: {es-port}

deployment yaml file
front-envoy:
    image: envoyproxy/envoy:v1.19.0
    command: "/usr/local/bin/envoy -c /etc/envoy-config.yaml --component-log-level http:debug,router:debug,ext_authz:debug"

The issue was noticed when custom header was NOT forwarded by envoy to auth server when configured as below.
authorization_request:
                          allowed_headers:
                            patterns:
                              - exact: "UPPERCASE-custom-header"

working config :
authorization_request:
                          allowed_headers:
                            patterns:
                              - exact: "lowercase-custom-header"

Unfortunately our auth server relies on a vhost style routing setup; we're unable to upgrade to 1.18.x as there appears to be no way to use the host from the 'uri' field or any other way to specify it, instead we're forced to use the host value from the original request.

My team is hitting this exact same issue and are unable to upgrade to > 1.18.  Our auth server also relies on the Host header matching its hostname (vhost setup).  Has anyone found a workaround?

Apologies for posting on a very old issue; however I was wondering if there was any movement on this issue? We're running into the same issue and ideally would like to use a HTTP serivce with a static method and path for our auth server and the direction in this issue sounds very promising.

Same to me, want to use HTTP auth service with single endpoint

same issue to me, hope to see new progress.


Event not being fired or fired with no value

Hey all! I know you have this note:
Note: some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try switching tabs and then switching back.
But I realized that a few times the events are not being fired at all or with no value attached. This is the implementation based on the console.log example that you have it.
import { getCLS, getFID, getLCP } from "web-vitals";

const sendToNR = (event, value) => {
  if (window.newrelic) {
    window.newrelic.setCustomAttribute(event, value);
  }
};

const startSiteSpeed = () => {
  getCLS(metric => sendToNR("CLS", metric.value));
  getFID(metric => sendToNR("FID", metric.value));
  getLCP(metric => sendToNR("LCP", metric.value));
};

Is there anything wrong here? Also, is there an accurate way to test these metrics? The Google Chrome extension shows really different numbers for the same page.

The first item was already fixed! thanks!
Now about the Google Chrome extension, if you load any page at different times you will get quite a few different results.

The first item was already fixed! thanks!

Great!

Now about the Google Chrome extension, if you load any page at different times you will get quite a few different results.

Please file issues with the extension against that repo: https://github.com/GoogleChrome/web-vitals-extension/

👍


chore: release 1.0.0

:robot: I have created a release *beep* *boop*
1.0.0 (2019-05-13)
Bug Fixes

deps: update dependency google-gax to v1 (#93) (47a97dd)
DEADLINE_EXCEEDED retry code is idempotent (#94) (42f6c42)
deps: update dependency google-gax to ^0.26.0 (#81) (f26654a)

Build System

upgrade engines field to >=8.10.0 (#82) (47d1824)

Features

DEADLINE_EXCEEDED is no longer retried; attemptDeadline option has been introduced (86d0e4f)

BREAKING CHANGES

upgrade engines field to >=8.10.0 (#82)

Release is at https://github.com/googleapis/nodejs-scheduler/releases/tag/v1.0.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


[Crunchyroll] Log In support

Checklist

[X] I'm reporting a site feature request
[X] I've verified that I'm running yt-dlp version 2021.10.22. (update instructions)
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Example URLs
https://beta.crunchyroll.com/it/watch/G8WUN2ND8/La-citt-delle-bestie-magiche-coperta-di-neve
https://beta.crunchyroll.com/watch/GJWU2J7Z8/Clash-Class-A-vs-Class-B
Description
Like I said the in site support issue
https://github.com/yt-dlp/yt-dlp/issues/915
It is possible to not only support the website but also the login for crunchyroll.
Access to beta crunchyroll should be default in US for free and paid account (so you should be able to test this with a free account).
Like I said in the support site issue we already got two example on how to implement the log in support
https://github.com/hyugogirubato/Kamyroll-Python
the old basic script (really easy to understand)
https://github.com/hyugogirubato/Kamyroll-Python/blob/ffba19ec6f8c81dae4e5f35e368748fe2fca6494/kamyroll.py
and my own C# implementation (based on that old kamyroll python version, easier to understand at least for me)
https://github.com/federicorosso1993/Kamyroll-CSharp
I think the old crunchyroll log in support was already half broken (it required a cookies.txt file and the user agent), my own script and kamyroll-python do not require anything like that (my own implementation and the old version of kamyroll used this kind of code
var cookie = cookieContainer.GetCookies(uri).Cast().FirstOrDefault(x => x.Name == "etp_rt");
in C# and a code like this
r = requests.get(endpoint)
etp_rt = r.cookies.get("etp_rt")

in python
So it should be possible to avoid the request of a cookie file from the user. I know that the new kamyroll implemetation in python don't even need that since it use the mobile api to log in.
The old implementation use the desktop app api.
My own implementation got also a comment with the web API implementation to log in (I made it as a comment because the desktop app api it's already working as an alternative).
You can use this page
https://www.crunchyroll.com/welcome/login
and this page
https://www.crunchyroll.com/originals/it/index.html
to find the basic auth code (in a get with this url https://api.crunchyroll.com/start_session.0.json?sess_id=1&device_type=com.crunchyroll.static&device_id=whatvalueshouldbeforweb&access_token=giKq5eY27ny3cqz )
It's always the same value and it will work to start the log in.
Not sure how to implement it in a large python app like yt-dlp (I'm not really skilled with python) but the code it's already done and it's working in another app (made just to fix youtube-dl and now yt-dlp).

FYI, if you're ok with using cookies rather than a proper login, #2506 implements that. Any login system that gets you an etp_rt cookie should integrate with that without hassle as well. Other mechanisms would probably need to alter the way auth_response is generated.

Is including static 'access tokens' like kamyroll does a legal issue yt-dlp wants to avoid? If it isn't, I'd be happy to whip up a login mechanism for the beta extractor based on what the current version of kamyroll is doing. It's a pretty small addition to what I do in #2506. Basically just generate auth_response differently, supplying a hardcoded basic token copied from kamyroll in the Authorization header and putting grant_type=password&username=<username>&password=<password>&scope=offline_access in the post data.

Is the "access_token" obtainable publically? ie, can it be deduced from the webpage or the requests that we get in the browser. If so, it is fine to hardcode it. If it is instead some sort of leaked key, that could have legal implications and is not something I want to deal with

Is the "access_token" obtainable publically? ie, can it be deduced from the webpage or the requests that we get in the browser. If so, it is fine to hardcode it. If it is instead some sort of leaked key, that could have legal implications and is not something I want to deal with

Yes. You can get it from here
https://www.crunchyroll.com/welcome/login
The access token is always the same
https://api.crunchyroll.com/get_upsell_data.0.json?sess_id=1&device_id=whatvalueshouldbeforweb&device_type=com.crunchyroll.static&access_token=giKq5eY27ny3cqz&referer=https:%2F%2Fwww.crunchyroll.com%2Fit%2Fwelcome%2Flogin

Then u can hardcode it. We do the same for other sites including youtube

The key used by the current kamyroll implementation (aHJobzlxM2F3dnNrMjJ1LXRzNWE6cHROOURteXRBU2Z6QjZvbXVsSzh6cUxzYTczVE1TY1k=) is datamined from the mobile app or its traffic, rather than the web site, afaik. The mobile app is freely available, but presumably has a EULA of some kind, unlike a web site. Still ok?

Not sure how to implement it in a large python app like yt-dlp (I'm not really skilled with python) but the code it's already done and it's working in another app (made just to fix youtube-dl and now yt-dlp).

I quote myself
"Not sure how to implement it in a large python app like yt-dlp (I'm not really skilled with python) but the code it's already done and it's working in another app (made just to fix youtube-dl and now yt-dlp)."
My own implementation is in a C# app
https://github.com/federicorosso1993/Kamyroll-CSharp

Hmm, ok. After some inspection, and your comments, I'm starting to see how the web login works, so I think I could implement that directly, without any hardcoded tokens. I'll work on it soon.

I also find it amusing that whatvalueshouldbeforweb is literally the device id... somebody used a template and never changed it I guess :-P

I gave it a shot, but the problem I'm running into is that I get a 403 Forbidden response from cloudflare, that wants me to prove I'm human with a captcha, when I try to download the login page (https://www.crunchyroll.com/welcome/login). Afaict this happens even when I'm sending the exact same http request as the browser does (for example, using the 'copy as curl' option from my browser's inspector), so I'm a bit stumped as to how to get around it.

On the plus side, the rest of the process works fine, so I went ahead and made a PR with the data from the login page hardcoded.

I gave it a shot, but the problem I'm running into is that I get a 403 Forbidden response from cloudflare, that wants me to prove I'm human with a captcha, when I try to download the login page (https://www.crunchyroll.com/welcome/login). Afaict this happens even when I'm sending the exact same http request as the browser does (for example, using the 'copy as curl' option from my browser's inspector), so I'm a bit stumped as to how to get around it.

I tried it again and you're right (it was working when I opened this ticket a while ago).
Right now I'm still using the access_token from the desktop app as default and that still work, but I understand that you cannot use any access_token.
Not sure how will you solve this problem but I'm glad you can.
Worst case scenario a solution could be to ask the user to input that

I tried to read your fix and if I understand it right you are still able to get the session_id with self._download_json on that url (not sure how that is different from a regular get)...

I think the difference is mostly that it's on api.crunchyroll.com rather than crunchyroll.com. The api.crunchyroll.com domain isn't cloudflare-happy. Unsurprisingly, given that it's intended to be accessed by non-browser software like the desktop and mobile apps, and the various streaming box apps as well.
The only thing I'm having trouble with is the login page itself, so I just hardcoded the data that would normally be in it, which hasn't changed, at least since you opened the issue, so I think we're good.

Ah, I realized I misunderstood you. self._download_json is a wrapper around urllib, and becomes a GET in this case because I used query=. data= would produce a POST instead.
My process starts with a session id from a GET to get_upsell_data.0.json, then logs in with a POST to login.1.json, which sets the etp_rt cookie needed for the beta extractor's call to auth/v1/token on the beta api (and presumably also the non-beta mechanism works on the same cookie).

Yes I can confirm that the same cookie is used on the non-beta website.
Thank you for your explaination. I actually misunderstood you too since I tried a GET on postman-like website of  https://api.crunchyroll.com/get_upsell_data.0.json?sess_id=1&device_id=whatvalueshouldbeforweb&device_type=com.crunchyroll.static&access_token=giKq5eY27ny3cqz&referer=https:%2F%2Fwww.crunchyroll.com%2Fit%2Fwelcome%2Flogin and it gave me the cloudflare error so I was under the impression that it did not work anymore even with hardcoded access_token, device_type, device_id, sess_id.
So I'm glad it's working on python (maybe if I'll try again in an actual application it will work too).

Yes I can confirm that the same cookie is used on the non-beta website.

Good. That raises my confidence that this code will work for non-beta users.

I tried a GET on postman-like website of [...] and it gave me the cloudflare error so I was under the impression that it did not work anymore [...]. So I'm glad it's working on python (maybe if I'll try again in an actual application it will work too).

Just running curl on that url (with no special flags) works fine for me with no cloudflare issues, so it can't be too sensitive, since that command would send an honest user-agent string identifying as curl. Maybe it's more sensitive in some regions of the world than others?

I didn't even tried curl.. No you are right it's working and since I'm in italy I don't think it's more sensitive in some regions.
My mistake was to trust a website to make an API call, but I was outside just a while ago.

Ah, ok. Good. I was worried my code might not work in some places.

Cloudflare probably just thinks that specific IP is suspicious


Adding an experimental notebook comparing 3 approaches to standardization

Comparison of using: default approach (standardizing and scaling between -1 to 1), using log10, using inverse hyperbolic sine.

I have incorporated Emily's changes into the standardize_and_scale function. Now, the experimental notebook includes a comparison of four different ways of standardizing. Additionally, I have eliminated the extra step of scaling in the log10 and sigmoid methods.

Thanks @Niklewa, this looks great!! I'll merge this PR with elm-standard-standard now, and let you or @rfl-urbaniak merge that into runl-generalize-weights.  Then I'll be excited to explore more alternative scaling approaches.


the apt default option --no-install-recommends causes problems with cython

I am not sure if changing this default is the best way of solving this problem, but when I use cython in my containers, the no-install-recommends option causes cython to fail, because of missing packages. I guess you had this option to reduce the size of containers?

Codecov Report

Merging #194 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #194   +/-   ##
=======================================
  Coverage   81.37%   81.37%
=======================================
  Files          33       33
  Lines        1471     1471
  Branches      146      146
=======================================
  Hits         1197     1197
  Misses        207      207
  Partials       67       67

Impacted Files
Coverage Δ

neurodocker/interfaces/_base.py
76.54% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fe7c750...6bf4bff. Read the comment docs.

hi @stebo85 - it's possible to remove the --no-install-recommends on the command-line, though i realize this is undocumented.
you would use apt_opts after the --install flag.
on a base image that uses yum, you would use yum_opts after --install.
for example:
$ docker run --rm kaczmarj/neurodocker:0.4.0 generate docker \
    -b debian:stretch -p apt \
    --install apt_opts='--quiet' git vim

i realize that trying to do apt_opts='' does not remove the --no-install-recommends, and that's a bug.
does this work for you? if you are willing, i would appreciate a pr to document this behavior (so those contributions could be attributed to you).

cool, the command line option --install apt_opts='--quiet' works and it removes --no-install-recommends. Then you can ignore the change I made. I can describe this apt_opts command in the README.md if this helps you or would you rather like it as a bug report so you can tackle that at a later stage?
It took me quite some time and luck to find out that this option was causing the problem, because the cython error inside the container doesnt really indicate what is wrong:
Traceback (most recent call last):
File "setup.py", line 75, in
extensions = [make_ext(modname="TGV_QSM/qsm_tgv_cython_helper", pyxfilename="TGV_QSM/qsm_tgv_cython_helper.pyx")]
File "setup.py", line 55, in make_ext
if check_for_openmp():
File "setup.py", line 44, in check_for_openmp
stdout=fnull, stderr=fnull)
File "/usr/lib/python2.7/subprocess.py", line 168, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.7/subprocess.py", line 390, in init
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

@stebo85 - can you please file the bug, i will fix it soon, and then perhaps you could update the examples readme.
really sorry that it took a lot of time to debug your error. we can include somewhere that if users are running into strange issues with their container, they can try --install without --no-install-recommends.

and i include --no-install-recommends by default to minimize container size. it makes a big difference in some cases, but of course it can lead to ambiguous issues in other cases, as we see here.

ok, I opened an issue and made the changes for this pull request. Not sure if I got this right with the Pull request - let me know if I did something wrong.
Thank you
Best
Steffen

This looks great, thank you very much!


Constructor id arguments don't need to be listed first

Fixes #2541

Coverage increased (+0.003%) to 87.302% when pulling b891b5b953086f492b28ae22ef6169079345363a on Condor70:master into 8c5474b5dde0ca3aea1e4fdae7603dde81481912 on mybatis:master.

Thank you, @Condor70 !


ci: enable tracking of policy enforcement latency in scale test

Please ensure your pull request adheres to the following guidelines:

[ ] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[ ] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[ ] All commits are signed off. See the section Developer’s Certificate of Origin
[ ] Provide a title or release-note blurb suitable for the release notes.
[ ] Are you a user of Cilium? Please add yourself to the Users doc
[ ] Thanks for contributing!

Fixes: #issue-number
<!-- Enter the release note text here if needed or remove this section! -->

hmm, seems like I might be missing some other config. Some of the queries are not giving any results:
2024-05-14T11:45:05.5266079Z W0514 11:45:05.525624    7212 generic_query_measurement.go:169] query returned no samples for Network Policy Enforcement Latency: PolicyCreation - TargetCount
2024-05-14T11:45:05.5267897Z I0514 11:45:05.525729    7212 generic_query_measurement.go:208] bounded query: histogram_quantile(0.5, sum(policy_enforcement_latency_policy_creation_seconds_bucket)


Feature/alias index

Add alias_index.sh script which will check if an ElasticSearch index has a given alias, the alias will be removed for that index, before a given index name is aliased
Add step in Jenkinsfile to call alias index script

E.g. given a current index bi-dev-january-2018 exists with a bi-dev alias, if a new index bi-dev-august-2018 is passed in to the script with an alias bi-dev, the bi-dev alias will be removed from bi-dev-january-2018 and added to bi-dev-august-2018.
Note: at the moment, the alias_index.sh script can only handle de-aliasing one index due to the difficulty of parsing JSON in shell scripts without external dependancies. This should not be an issue as one index should only ever have one alias, a future PR will solve this issue.
A future PR will deal with parameters for passing in an environment, so that no index name needs to be specified, instead being generated.

As you're writing a few of these, I'm going to raise some styling concerns to fix. You may wish to backport these into other scripts, but not a big concern.

@willis7 I'll create a ticket to go back and refactor the other scripts. I'll also add a CONTRIBUTING.md with links to the shell style guide etc.


Include timing information in leadership tracer events

@karknu suggested that this could help a node operator determine if their node needs more resources. EG If the TraceNodeNotLeader was coming out near the end of each slot, that suggests that their machine is just barely managing to check each slot -- it'll likely start missing some checks if eg some additional CPU load arrived.

@karknu some questions.

You called out TraceNodeNotLeader. I can imagine a couple reasons why. Question: did you exclude the TraceAdoptedBlock event (ie found it led, then forged and adopted a block) intentionally? Because it's expected to be quite a bit slower (costs of creating the block) and so we wouldn't want to skew a derived metric? And it's an OK outlier to ignore because it's much rarer than TraceNodeNotLeader?

We think it would be easier on us to instead add eg the UTC time of the start of the slot and the slot's length to the TraceStartLeadershipCheck event. We imagine the downstream metric logic could work with that, eg by calling getCurrentTime as part of the TraceNodeNotLeader and then subtracting the "slot start time" from the latest TraceStartLeadershipCheck event. (All events form the same check are labeled with the same "current slot" field.) (We'd like to avoid including the bookkeeping/state maintenance in the Consensus layer.) Do you think that still provides the necessary information for what you had in mind?

Thanks.

@karknu some questions.
* You called out `TraceNodeNotLeader`. I can imagine a couple reasons why. Question: did you exclude the `TraceAdoptedBlock` event (ie found it led, then forged and adopted a block) intentionally? Because it's expected to be quite a bit slower (costs of creating the block) and so we wouldn't want to skew a derived metric? And it's an OK outlier to ignore because it's much rarer than `TraceNodeNotLeader`?

I did not consider TraceAdoptedBlock, however I think it does provide a useful metric on its own. That is how long does it take for the BP to forge a block.

* We think it would be easier on us to instead add eg the UTC time of the start of the slot and the slot's length to the `TraceStartLeadershipCheck` event. We imagine the downstream metric logic could work with that, eg by calling `getCurrentTime` as part of the `TraceNodeNotLeader` and then subtracting the "slot start time" from the latest `TraceStartLeadershipCheck` event. (All events form the same check are labeled with the same "current slot" field.) (We'd like to avoid including the bookkeeping/state maintenance in the Consensus layer.) Do you think that still provides the necessary information for what you had in mind?

I think that would work fine, the bookkeeping can be done in cardano-node's Tracers.hs


AllDebrid Servers are not allowed

Description
As a developer, I want to fix the AllDebrid API error when using it with production server. The AllDebrid working perfectly in local when running the add-on locally. But using it with server then getting following error.
ERROR::26-Dec-23 16:27:25 - Exception occurred: Failed to add magnet link to AllDebrid {'status': 'error', 'error': {'code': 'NO_SERVER', 'message': "Servers are not allowed to use this feature. Visit https://alldebrid.com/vpn if you're using a VPN."}}

@MrMonkey42 I see you have integrated the alldebrid in your add-on. Any idea on this error?

Implementation PR https://github.com/mhdzumair/MediaFusion/pull/55

Update: I think that AllDebrid has IP-based detection. it's even detected as server access when I try to use API for adding magnet in a fresh EC2 server with only SSH service that allows only for my local IP.

@mhdzumair My addon doesn't actually have any functionality to add new magnet links. It only reads existing files already downloaded in the cloud.
However, Torrentio does add new magnets to AllDebrid.
https://github.com/TheBeastLT/torrentio-scraper

Getting user's torrent API /magnet/status is working. But it won't allow /magnet/upload for adding a torrent.

However, Torrentio does add new magnets to AllDebrid.

Yes. I was desperate to hear about his secret sauce. I have gone through his code implementation, which is not fancy. But they deployed the service on their own servers.
My assumption is, Either that server IP address is not get detected or AllDebrid whitelisted it.

As expected, I believe client-side API calls is the key and it's highly likely Torentio is doing the same thing.

They restrict the add magnet API endpoint. But the other endpoint seems to be working. So I'm thinking of redirecting the add magnet endpoint from stremio. So that it will run the API call from local. But I think it might give video error on first try and then second call will respond it from server.
I'll try this method.

its not only download the magnet. but also the link unlock endpoint also not allow it to be run in the server. the only way is to use the alldebrid is from local addon or using local redirector for atleast to parse the unlock link. i have setup a minimal repo https://github.com/mhdzumair/alldebrid-redirector. at minimum you need to setup this in your local and then you can use alldebrid with stremio.
is it possible to run a python script in your local? if so i can proceed the further development to add local redirector service link in the main addon config page. otherwise it wast of energy to focus more on this specific problem.

Is the problem fixed omor does it have workaround for alldebrid.

@nityanantan23 for now, you need to set up the addon in local to work with alldebrid.

@mhdzumair can I have a step by step guide on how to run it locally

here is the detailed guideline to setup the MediaFusion easily https://github.com/mhdzumair/MediaFusion/blob/develop/deployment/README.md


Theme Context for Class Components

💬 Question
Is it possible to have a code example UI Kitten Theme Context for Class Components ? i'am new to UI Kitten.

In class components you may need to use withStyles HOC to use theme.
https://akveo.github.io/react-native-ui-kitten/docs/components/using-theme/overview
Please check this guide for details:
https://akveo.github.io/react-native-ui-kitten/docs/design-system/use-theme-variables

In class components you may need to use withStyles HOC to use theme.
https://akveo.github.io/react-native-ui-kitten/docs/components/using-theme/overview
Please check this guide for details:
https://akveo.github.io/react-native-ui-kitten/docs/design-system/use-theme-variables

U can wrap class into fn to use hooks
import { useTheme } from '@ui-kitten/components';

class XYZ extends Component {
    constructor(props) {
        super(props);
        this.state = {
        };
    }

    render() {
        const { theme } = this.props;
        return (
            <>
            </>
        )
    }
}

export default function (props) {
    const theme = useTheme();
    return <XYZ {...props} theme={theme} />;
}


feat(repo): creating pr test action

The purpose of this workflow is to build and run our tests when someone creates a PR. This will allow developers to catch issues sooner and proactively fix their PRs before they are reviewed.

Do not merge until @xero reviews.

This is working since it has found the failing test:
Summary of all failing tests
FAIL packages/plugin-leanplum/test/index.test.ts
  ● plugin-leanplum › ios

So for the last step we are going to change the Flagship Code CLI to throw a process.exit(1) if it's being run in a CI and has a failure otherwise it will exit it 0. So as it stands now this PR is ready to be reviewed.

checkout
https://michaelheap.com/improve-your-github-actions-security/


Update std and check if socket is closed

I am checking out your library and so far it looks promising!
However, after setting up the deno server, it would crash with error: Uncaught (in promise) ConnectionReset: Socket has already been closed.
I've added a check to return if the socket is closed:
https://github.com/Jack-Works/async-call-rpc/blob/12cbb823f67d7da27a491f042ba1a29a67e1d3f6/utils/deno/websocket.server.ts#L28-L31
if (websocket.isClosed) return

Also, the std is quite outdated, so I've updated it to @0.106.0
https://github.com/Jack-Works/async-call-rpc/blob/12cbb823f67d7da27a491f042ba1a29a67e1d3f6/utils/deno/websocket.server.ts#L1-L2

This seems to work now, but still might need to be tested. Please let me know what you think and if this can be updated here.

Hi! Thanks for your interest! You can create a PR to fix this or if you don't want to, I can do it.

I've sent the PR for the isClosed bug.
But keeping the same std version as the functions/types such as acceptWebSocket, WebSocket are deprecated in deno stable.

I have published 6.0.1


add_common_builds for Windows assumes mingw

After upgrading to 0.2.20, I'm getting:
Traceback (most recent call last):
  File "build.py", line 18, in <module>
     builder.add_common_builds(pure_c=False)
   File "C:\Users\Jenkins\AppData\Roaming\Python\Python27\site-packages\conan\packager.py", line 124, in add_common_builds
     if self.mingw_builds(pure_c):
   File "C:\Users\Jenkins\AppData\Roaming\Python\Python27\site-packages\conan\packager.py", line 95, in mingw_builds
    version, arch, exception, thread = config
    ValueError: need more than 1 value to unpack

Looks like mingw_builds needs to check if mingw_configurations is empty?
        for config in self.mingw_configurations:
            version, arch, exception, thread = config

Yes, this is a bug, sorry for the inconvenience. I have just submitted a PR #24 that should fix it.
While a new release of conan-package-tools is done, you could try to install a previous version of conan-package-tools with pip. Or maybe, add just one mingw configuration to your build, that would also help to test this new feature. You could add to your build.py something like:
builder = ConanMultiPackager(..., mingw_configurations=["4.9@x86_64@seh@posix"])

Thanks for reporting!

I have had success reverting to 0.2.16 in my appveyor.yml:
install:
  - set PATH=%PATH%;%PYTHON%/Scripts/
  - pip.exe install conan_package_tools==0.2.16 # It install conan too
  - pip.exe install conan --upgrade
  - conan user # It creates the conan data directory

Thanks for fixing! Looking forward to 0.2.21 :-D

Hi! I think we better keep this issue open, until 0.2.21 is released, so other users can easily see the status of this issue. We have a policy for the main conan repo, is to add a "fixed" label, but do not close the issue until it is released and tested in the release. Cheers!

0.2.21 is available. Sorry for the delay!


Inject a default tracer (callTracer), with a sane configuration, to allow for generating the current traces that ENs generate

Completed by https://github.com/onflow/flow-evm-gateway/pull/632


Error: cannot fetch messages within range "{}"

I want to use himalaya with 2 accounts:
1 works for and this one does not:
[mymain]
default = true
email =<EMAIL_ADDRESS>
imap-host = "mail.myhomepage.xyz"
imap-port = 143
imap-starttls = true
imap-login =<EMAIL_ADDRESS>imap-passwd-cmd = "pass show<EMAIL_ADDRESS>
smtp-host = "smtp.web.de"
smtp-port = 587
smtp-starttls = true
smtp-login =<EMAIL_ADDRESS>smtp-passwd-cmd = "pass show<EMAIL_ADDRESS>
I get the error msg:
Error: cannot fetch messages within range "{}"
Caused by:
Unable to parse status response "{}"
I see the mailboxes but just not the messages

It looks like the IMAP server returns a bad response. Did you try to
activate the debug mode to have more information? This account works
well elsewhere?
--
Cordialement
Clément DOUIN
Développeur Web Full-Stack
https://soywod.me

These server settings work on Thunderbird and K9Mail (Android).
I ran the command with the -l debug options but the output is the same.

Duplicate https://github.com/soywod/himalaya/issues/276.


uninterleave and interswap

I am agnostic on the names!

data Infinite a = a :< Infinite a
  deriving Foldable

infixr 5 :<

-- | Interleave two infinite lists.
interleave1 :: Infinite a -> Infinite a -> Infinite a
interleave1 (l :< ls) ~(r :< rs) = l :< r :< interleave1 ls rs

interleave2 :: Infinite a -> Infinite a -> Infinite a
interleave2 (x :< xs) ys = x :< interleave2 ys xs

nats = go 1 where
  go n = n :< go (succ n)

test s = Prelude.toList s !! 1_000_000_0

λ :set +s
λ test $ interleave1 nats nats
5000001
(4.90 secs, 3,169,926,688 bytes)
λ test $ interleave2 nats nats
5000001
(5.49 secs, 3,609,926,744 bytes)

Is there any prior art or applications for these functions?

You can use uninterleave like you would use Supply from streams. It also has the nice property that stitching streams together with these primitives is fully reversible, and this property is unique to infinite streams!

I can find limited prior art for uninterleave, but not for interswap. I appreciate your contribution, but let's leave interswap aside. We cannot really provide all possible helpers and combinations.
With regards to uninterleave, could you please make it lazier? E. g., head (fst (uninterleave ('a' :< undefined))) should succeed.
Performance measurements in ghci are typically unreliable and unrepresentative for compiled code. If you want to make a case about performance, may I suggest you to write a benchmark suite using tasty-bench?

The old interleave implementation seems to be faster in compiled code!

I wrote some benchmarks for uninterleave. They seem to support my statements about performance from the comments, and we can gain about 30% by implementing uninterleaveR in terms of uninterleaveL.
However, I am not happy about "warmup dummy" in my benchmarks! Perhaps you could offer some insight?

I like your uninterleave3 the most: it is better not to clutter the top level name space. You can make it even sweeter, expressing uninterleaveL via uninterleaveR and vice versa, avoiding irrefutable pattern matching.

It is half the speed of uninterleave1 though. That's a very steep price for not having top level definitions, that we don't export anyways

I'm sorry, I don't follow. The benchmarks you quoted above (https://gist.github.com/BlackCapCoder/9532582173b487ab0c073bd906042d0e) show that uninterleave3 is the fastest one, slightly faster than uninterleave1. How come that it's now half the speed?

edit: I tried expressing uninterleaveL and uninterleaveR in terms of each other, and it's worse.

Can you give me a reproducible benchmark for this? Please make it a proper benchmark suite which I can run with cabal bench.

I've added an empty benchmark suite, feel free to populate it.

I added some benchmarks; I think I've just been looking at the wrong number. I've been looking at the total time!
uninterleave7 is with local definitions and L/R in terms of each other
All
  uninterleave1: OK (3.59s)
    125  ms ± 9.3 ms, 512 MB allocated,  25 KB copied, 1.4 GB peak memory
  uninterleave2: OK (1.54s)
    120  ms ± 4.5 ms, 512 MB allocated,  24 KB copied, 1.4 GB peak memory
  uninterleave3: OK (4.05s)
    405  ms ±  28 ms, 2.2 GB allocated, 116 KB copied, 1.5 GB peak memory
  uninterleave4: OK (1.65s)
    417  ms ±  10 ms, 2.2 GB allocated, 112 KB copied, 1.5 GB peak memory
  uninterleave5: OK (2.12s)
    440  ms ±  12 ms, 2.5 GB allocated, 114 KB copied, 1.5 GB peak memory
  uninterleave6: OK (1.71s)
    125  ms ± 9.3 ms, 512 MB allocated,  20 KB copied, 1.5 GB peak memory
  uninterleave7: OK (0.70s)
    116  ms ± 5.4 ms, 512 MB allocated,  19 KB copied, 1.5 GB peak memory

Oops, this was unintentional. Feel free to rebase and reopen.


Documentation stil talks about assert_approx_{eq, ne}!

It should be assert_relative_{eq, ne}! instead.

There is also mention of the ApproxEq trait, but it seems to have been renamed to RelativeEq(?)


Bug: Ionic serve failed to load (typescript 0.0.47 and 0.0.48)

Everytime I save a page, the page does not refresh in the web browser (ionic serve -all)
Looking at my terminal console, I get the following error.
UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 5): TypeError: Cannot read property 'send' of undefined
I'm using ionic 2.1.8 (typescript 0.0.47), node 6.9.1, running on ubuntu 16.04.

It looks like you have an unhandled promise rejection in your code. Try looking for the usage of the .send function and see if you are missing a .catch(console.log) on that promise.

It was a fresh project downloaded (ionic start myApp blank --v2 --ts), and the only thing I changed was the home.html file.
What I observed is that the fresh 'blank' project loaded uses the (0.0.47 typescript), which all this while whenever I download a new project, the console prompts me I'm using 0.0.45 typescript, which runs perfectly well on my current install of ionic 2.1.8, with nodejs 6.9.1.
Could it be possible that the starter files using typesript 0.0.47 are broken, or incompatible with my current ionic + nodejs install?
Appreciate further advise here. Thank you.

Could you please update to ionic-app-scripts version 0.0.48 and probably also share ionic info output.

The problem persists though I installed the latest app-script (0.0.48). When I update home.html, the error in bold further below shows up. Any advise?
My ionic info
Ionic Framework Version: 2.0.0-rc.4
Ionic CLI Version: 2.1.8
Ionic App Lib Version: 2.1.4
Ionic App Scripts Version: 0.0.48
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Linux 4.4
Node Version: v6.9.1
Xcode version: Not installed
When I run ionic serve and update home.html

ionic-hello-world@ ionic:serve /build/myapp
ionic-app-scripts serve

[18:12:30]  ionic-app-scripts 0.0.48
[18:12:34]  watch started ...
[18:12:34]  build dev started ...
[18:12:34]  clean started ...
[18:12:34]  clean finished in 35 ms
[18:12:34]  copy started ...
[18:12:34]  transpile started ...
[18:13:03]  transpile finished in 28.44 s
[18:13:03]  webpack started ...
[18:13:04]  copy finished in 29.49 s
[18:13:15]  webpack finished in 12.10 s
[18:13:15]  sass started ...
[18:13:17]  sass finished in 2.72 s
[18:13:17]  build dev finished in 43.37 s
[18:13:18]  watch ready in 43.65 s
[18:13:18]  dev server running: http://localhost:8100/
[18:14:03]  build started ...
(node:67) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: Cannot read property 'send' of undefined

Which version of typescript are you using?

Within my package.json dependencies, it states "typescript": "2.0.9".
I'm practically working on brand new 'blank project', and only started inputing some text in the home.html file.
Does the version of typescript break the ionic serve process?

Now everything just broke Having done the following:

npm install @ionic/latest
npm install -g ionic/latest

Nothing compiles now, with the below output error:
There was an error serving your Ionic application: Error: Cannot find module 'cross-spawn-async'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.runIonicScript (/usr/lib/node_modules/ionic/lib/utils/npmScripts.js:22:15)
at /usr/lib/node_modules/ionic/lib/ionic/serve.js:71:27
at _fulfilled (/usr/lib/node_modules/ionic/node_modules/q/q.js:787:54)
at self.promiseDispatch.done (/usr/lib/node_modules/ionic/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch (/usr/lib/node_modules/ionic/node_modules/q/q.js:749:13)
at /usr/lib/node_modules/ionic/node_modules/q/q.js:557:44

@thinktinker : seems like your ionic latest update was not installed successfully. Please try running command npm install -g ionic@latest and ensure it runs fully. Also delete node_modules from project folder and re-run npm install in project.

Have been doing this for one whole night.
I'm certain that the new blank starter projects have dependencies that do not work with my current ionic set up - which is an older set up (below). It's a same. Shouldn't there be some backward compatibility of the starter projects with previous RCs of ionic 2?
This is my current set up
Ionic Framework Version: 2.0.0-rc.4
Ionic CLI Version: 2.1.8
Ionic App Lib Version: 2.1.4
Ionic App Scripts Version: 0.0.48
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Linux 4.4
Node Version: v6.9.1
Xcode version: Not installed

This issue was moved to driftyco/ionic-app-scripts#599

Hi jgw96. Is this issue fixed? Otherwise, why is it closed?

Hello @thinktinker . So I closed this issue and moved it to the app-scripts repo which you can see the link to in my above comment. The reason for this move was because this issue is actually an app-scripts issue and not a framework issue.

Thanks for the heads up.
Is there a way for me to download a 'blank' project based on 0.0.45 whenever I call 'ionic start myapp blank --v2 --ts'?
Current requests of such serves me a 0.0.47 typescript which breaks in my current ionic development environment.

I have the same issue.My @ionic/app-scripts version is 0.0.47. So,could you tell me how to change my  @ionic/app-scripts version to 0.0.45

I have found my issue. I had changed the structure of directory when I add android platform. I had rename index.htm to main.html, and add another index.html.So,change it back.The ionic serve work well.


Update test results from pytest.

(fixes #14866)
Note: I will be updating for eslint once reviews are done.

https://github.com/microsoft/vscode-python/pull/15349#discussion_r573237506


Prevent unnecessary electron popup windows while clicking on links.

Prevent Default behaviour of links that are auto generated in services.
Description

Remove check event.disposition !== 'new-window' so that we can handle event.preventDefault() for links with
Add event.preventDefault() in main process. event.preventDefault() does not work in renderer - Ref - ,

This fix should work the unnecessary opening of electron windows in all recipes.
Motivation and Context
This fixes #666, #636
How Has This Been Tested?
This has been tested in Dev environment on Google Keep Recipe
Screenshots (if appropriate):

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project (run $ yarn lint).

@kytwb Can you please review this?

Not sure if it is this causing the problem but it sounds like it could be related.
In the 5.6 beta, clicking a link opens a new Ferdi Window but when Ferdi is running in the Fullscreen Mode on MacOS the new window cannot be closed even when taken out of fullscreen mode as it has no titlebar or close controls.

this is still happening in 5.6.0-beta2 @mahadevans87 @kytwb

Can confirm, also see this happening on 5.6.0-beta2
The workaround of right click > Open Link works as expected; but left click is not handled correctly.


feat: make cxx core more extensible

Summary
Make cxx core more extensible for Cxx TurboModules and RN 0.75
Min required versions:

Expo 51 ✅
react-native 0.74 ✅
web (no changes) ✅
SSR (no changes) ✅
Android  ✅
iOS ✅
react-native-macos (awaiting 0.74 release, should work out of the box) ❓
react-native-visionos (in testing) 🟡
react-native-tvos (in testing) 🟡
Windows (in progress) ❌

Min required versions:

Expo 51 ✅
react-native 0.74 ✅
web (no changes) ✅
SSR (no changes) ✅
react-native-macos (awaiting 0.74 release, should work out of the box) ❓
react-native-visionos (in testing) 🟡
react-native-tvos (in testing) 🟡
Android (in progress) ❌

@jpudysz thank you for this: android set root view background color

No problem 😇


Update stable version in repo from 2.0.2 to 2.2.0

Think about update stable version to 2.2.0
Version: stable=2.0.2 (121 days old) => latest=2.2.0 (18 days old)
Installs: stable=220 (49.33%), latest=23 (5.16%), total=446
Click to use developer portal
Click to edit
Do not close this issue manually as a new issue will be created if condition for update still exists.
Please drop a comment if any reason exists which blocks updating to version 2.2.0 at this time.
Note: This is an automatically generated message and not personally authored by bluefox!
@mcm1957 for evidence

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 2.2.0 but the current stable version is already 2.2.0.
So this issue should be closed.
@mcm1957 for evidence


community: Fix branch not being considered when using GithubFileLoader

Description: Added ref query parameter so data is not loaded only from the default branch but any branch passed

@baskaryan could you have a look at this fix? Thanks :)


Links to some user guides redirects to github

Link to "Guides > Testing & Monitoring > Simulating Large Test Workload" redirects to github page with examples in 1.2 branch. Is this intentional?

Another example:
"Guides > Testing & Monitoring > Using Explorer to Examine the Runtime Environment"

Yes; examples/ stays in the main repo (for now).


Gui off by 1 error in paging container instances

Marathon 0.8.0 (Didn't see a closed issue)
If you scale to 8 instances, 7 are displayed in the list on 1 page
If you scale to 9 instances, 7 are displayed on first page, 2 more are on page 2

This has been fixed in 0.8.2