Answers.Body: <p>Does the webserver support compression? Might be a disabled module (e.g. mod_gzip in apache). The Accept-Encoding suggests only compressed data is accepted.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-29T18:11:34.337Z
Answers.Text: Thanks - I've tried changing the Accept-Encoding header to various things including * and all fail.  On a different system I've also tried the same changes and I can't get that to fail so I'm wondering with it really is a 406 or something else that is wrongly identifying.
Answers.UserDisplayName: Aidan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-29T18:44:32.077Z
Answers.Text: If you're seeing a 406 status, I do think it'll be coming from your webserver or Joomla and not CiviCRM. CiviCRM's HTTP response code vocab doesn't include 406 AFAIK. Any of those `Accept*` headers could trigger a 406 if the application couldn't satisfy them.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-29T22:02:17.680Z
Answers.Text: Maybe a .htaccess file that is weird. It's possible for mod_rewrite for example to be told to return 406 for certain url patterns. Or maybe mod_security blocking it and returning 406.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-21T22:31:13.783Z
Answers.LastActivityDate: 2018-11-21T22:31:13.783Z
Answers.UserDisplayName: Demerit
Body: <p>I'm dealing with a system where the Quick Search box is not working.  Using the browser dev tools shows ajax requests being sent but receiving a '406 Not acceptable' error.</p>
  
  <p>According to <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406</a> this relates to content negotiation.</p>
  
  <p>The AJAX URL is:</p>
  
  <pre><code>https://example.com/administrator/?option=com_civicrm&amp;task=civicrm/ajax/rest&amp;entity=contact&amp;action=getquick&amp;json={"name":"a","field_name":"","table_name":"cc"}
  </code></pre>
  
  <p>and the content negotiation headers in the request are:</p>
  
  <pre><code>Accept: application/json, text/javascript, */*; q=0.01
  Accept-Encoding: gzip, deflate, br
  Accept-Language: en-GB,en;q=0.5
  </code></pre>
  
  <p>This matches what I see on another system that is working normally.</p>
  
  <p>This is CiviCRM 5.5.2 on Joomla 3.8.13</p>
  
  <p>Any ideas?</p>
  
Tags: <joomla><quicksearch>
Title: QuickSearch not working
ThreadText: # QuickSearch not working
  
  (Asked by: username_0 on 2018-11-21)
  
  I'm dealing with a system where the Quick Search box is not working. Using the browser dev tools shows ajax requests being sent but receiving a '406 Not acceptable' error.
  
  According to <https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406> this relates to content negotiation.
  
  The AJAX URL is:
  
  ```
  https://example.com/administrator/?option=com_civicrm&task=civicrm/ajax/rest&entity=contact&action=getquick&json={"name":"a","field_name":"","table_name":"cc"}
  
  ```
  
  and the content negotiation headers in the request are:
  
  ```
  Accept: application/json, text/javascript, */*; q=0.01
  Accept-Encoding: gzip, deflate, br
  Accept-Language: en-GB,en;q=0.5
  
  ```
  
  This matches what I see on another system that is working normally.
  
  This is CiviCRM 5.5.2 on Joomla 3.8.13
  
  Any ideas?
  
  **Tags:** joomla, quicksearch
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-11-21. Score: 0
  
  Does the webserver support compression? Might be a disabled module (e.g. mod\_gzip in apache). The Accept-Encoding suggests only compressed data is accepted.
  
  > **Comments:**
  > **username_0**: Thanks - I've tried changing the Accept-Encoding header to various things including * and all fail.  On a different system I've also tried the same changes and I can't get that to fail so I'm wondering with it really is a 406 or something else that is wrongly identifying.  
  > **username_2**: If you're seeing a 406 status, I do think it'll be coming from your webserver or Joomla and not CiviCRM. CiviCRM's HTTP response code vocab doesn't include 406 AFAIK. Any of those `Accept*` headers could trigger a 406 if the application couldn't satisfy them.  
  > **username_1**: Maybe a .htaccess file that is weird. It's possible for mod_rewrite for example to be told to return 406 for certain url patterns. Or maybe mod_security blocking it and returning 406.  
  
  ---
  
  