Support Questions

Find answers, ask questions, and share your expertise

New Cloudera installation: Hue - Bad Request (400)

after a new cloudera installation (exactelly the same way I've already installed several times) when I try to access hue, I get the following error: Bad Request (400)


I've inserted (not helping) allowed_hosts=* in hue.ini.

In cloudera manager the hue service is shown as green.

With netstat -tunlp | grep 8888 => everything is fine:

tcp        0      0*               LISTEN      10519/python2.7



ps -ax | grep 8592
8592 ? Sl 0:09 python2.7 /opt/cloudera/parcels/CDH-5.10.0-1.cdh5.10.0.p0.41/lib/hue/build/env/bin/hue runcherrypyserver
14500 pts/0 S+ 0:00 grep --color=auto 8592


Installtion is in google cloud Ubuntu 14.04 LTS with one master (4cpu 26gb) one node (2cpu 13gb) 


Any advice would be appreciated

Best regards






hi mbigelow,


no, just used the standard db performed by the installation: embedded postgresql





Are you able to set up a MySQL instance (or another external DB), create the user, create the db, and point Hue to it?

hi mbigelow



thanks for your suggestion. I've now installed v5.9



Can you please escalate this ticket to product owner-mgr / devOps group etc. please and let me know as you're from Cloudera ? If you need anything pls let me know 😉


Best regards

I get that a lot (I own too many Cloudera t-shirts and sweaters) but I do not work for them.

@Romainr Has this already been reported or can your team test this out?

hi mbigelow,


sorry , thought you're working for cloudera. 


If you have any spare cloudera xxl-t-shirts pls let me know 😉



having the same issue:
tried it with Ubuntu 14 and Debian 8. Cloudera 5.10 Installer.bin with embedded database.

When connecting to http://externalip:8888 i receive a "bad request 400".
But i found something:


wget http://FQDN-HOSTNAME:8888/
--2017-02-06 13:31:22--  http://FQDN-HOSTNAME:8888/
HTTP request sent, awaiting response... 302 FOUND 

 2. External IP

--2017-02-06 13:33:10--
Connecting to connected.
HTTP request sent, awaiting response... 400 BAD REQUEST


On the same host the cm and other services are accessable without any problems.
Adding allow_hosts=* at /etc/hue/conf/hue.ini didnt help anything.

Seems that something is wrong wit 5.10


@cjervis   The same issue was reported by multiple persons, could you pls take a look?

Community Manager



@Romainr is the best to look into this one. If he doesn't respond today, I'll reach out to him personally. 

Cy Jervis, Manager, Community Program
Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.

Are you using CM? Could you check that the hue.ini has the correct
'allow_host=*' in the desktop section?


as written before.

Other apps like CM or resource manager are reachable and working without any problems only hue did not.

And yes as mentioned before
Adding allow_hosts=* at /etc/hue/conf/hue.ini didnt help anything.

hi Romainr, can you please escalate this ticket to cloudera devOps group ?




Best regards


You are probably not modifying the correct hue.ini, if you use CM, please
look at the generated hue.ini from the Hue role

hi Romainr,


allow_hosts=* at /etc/hue/conf/hue.ini didnt help anything


different hue.ini same error.


  # Set this to a random string, the longer the better.
  # This is used for secure hashing in the session store.

  # Execute this script to produce the Django secret key. This will be used when
  # 'secret_key' is not set.
  ## secret_key_script=

  # Webserver listens on this address and port


 and btw. /etc/hue/hue.ini is exactly the same cause it links to the same dir....

*Note:* To override a value in Cloudera Manager, you need to enter verbatim
each mini section from below into the Hue Safety Valve
Hue Service → Configuration → Service-Wide → Advanced → Hue Service
Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini


thx for the link added it exactly there via CM now.

Syntax like:


and gues what... no change bad request 400

Super Guru



If you are using a Cloudera Manager managed cluster, then you need to set hue.ini edits in:


Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini


Cloudera Manager will distribute that configuration to the process directory that is used to read in the configuration for Hue when it starts. So, if you update files directly, it should not impact the configuration for Hue.


I would recommend testing after making the updates to the Cloudera Manager safety valve and let us know if that helps at all ... make sure you have restarted Hue.


As another note, I installed a clean Ubuntu 14.04 instance and then installed 5.10.  Using the embedded DB for Hue, all sync and migrations ran well and I can log into Hue with no changes.  There must be another factor here that we are not seeing.  If the safety valve update and restart does not fix the issue, I'll try to come up with some other things we can check.



New Contributor



We have tried to do what you have suggested and this did not resolve our issue.

Though it should not matter - we are running Centos in AWS for our Cloudera environment. 


Safety valve update and restart does not fix the issue....



Super Guru



By default, hue will do a "socket.getfqdn()" in python and then split on the dots.  If there is more than 2 items derrived from the split, then the last two elements are joined by a dot and prepended with a dot.


For example, if "socket.getfqdn()" returns "" the returned value is:


This means that Hue will only be accessible to clients (browsers) that are coming from the domain.


This mechanism used to derive the default domain is new to CDH 5.10.  In 5.9, the default was "*".  That is why we are pretty sure that explicitly setting the following in the safety valve will resolve the 400 error:





The following shows the configuration in Cloudera Manager:




Hue must be restarted after making the change.

If this is done, Hue will allow access from any host/domain.


I know there has been a great deal of difficulty addressing the issue, but I hope that the above gives you some background on why we were focusing on allowed_hosts.


Please update us with your results.  So far I have not been able to find a good way of logging what caused the 400 error, but if you are using CDH 5.10, allowed_hosts is a good first try.







I believe this Hue code change was made for security reasons. The new default is that only hosts on the same domain as the Hue server are allowed to connect. 


As noted in the ini file comments, instead of allowing all domains to connect, one could also list out each allowed domain in a comma separated list:






@kfc @Burkhard @CloudOpsProd


Can you all post the stdout of Hue so we can confirm that it is the same issue and not just the same error?


Can you also detail how you installed CDH and specifically Hue?  Did you use parcels or packages?  Did you add it during the Cluster Install Wizard or using the Add Service Wizard?  Did you install it by hand?

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.