使用Mule 3.6 HTTP Connector的意外404 [英] Unexpected 404 using Mule 3.6 HTTP Connector

问题描述

使用新的HTTP连接器时出现意外的404错误，无法弄清原因.

I'm getting unexpected 404 errors using the new HTTP connector and can't figure out why.

此卷曲会发出与我尝试进行的呼叫相同的呼叫，并且会按预期工作:

This curl makes the same call I'm trying to make, and works as expected:

curl -H "X-AuntBertha-Signature: AUTH_SIG" \
    https://searchbertha-hrd.appspot.com/_ah/api/search/v1/programs/4818166?api_key=MY_API_KEY \
    > resources_dump.json

但是，此流程不起作用.供应商告诉我，他们甚至没有在日志中看到请求，所以有些时髦.

However, this flow does NOT working. Vendor told me that they don't even see the request show up in their logs, so something is funky.

<http:request-config name="AuntBertha_Production"  host="searchbertha-hrd.appspot.com" basePath="/_ah/api/search/v1/" doc:name="HTTP Request Configuration" port="443" protocol="HTTPS" />
<!-- clipped... -->

<flow name="FetchResource">
    <!-- clipped... -->

    <http:request config-ref="AuntBertha_Production" path="/programs/4818166" method="GET" doc:name="Fetch from AB">
        <http:request-builder>
            <http:query-param paramName="api_key" value="MY_API_KEY"/>
            <http:header headerName="X-AuntBertha-Signature" value="AUTH_SIG"/>
        </http:request-builder>
        <http:success-status-code-validator values="200,404,500"/>
    </http:request>

这是我在控制台中获得的日志(在此问题的帮助下)

And here are the logs I'm getting in my console (after help from this question):

DEBUG 2015-07-14 16:19:55,202 [[resource_bulk_upload].HTTP_Default_Listener.worker.01] com.ning.http.client.providers.grizzly.GrizzlyConnectionsPool: [poll] Found pooled connection [TCPNIOConnection{localSocketAddress={/192.168.0.2:49878}, peerSocketAddress={searchbertha-hrd.appspot.com/209.85.147.141:443}}] for uri [https://searchbertha-hrd.appspot.com:443].
DEBUG 2015-07-14 16:19:55,203 [[resource_bulk_upload].HTTP_Default_Listener.worker.01] com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider: REQUEST: HttpRequestPacket (
   method=GET
   url=/_ah/api/search/v1/programs/4818166
   query=api_key=MY_API_KEY
   protocol=HTTP/1.1
   content-length=-1
   headers=[
      Host=searchbertha-hrd.appspot.com:443
      X-AuntBertha-Signature=AUTH_SIG
      Connection=keep-alive
      Accept=*/*
      User-Agent=NING/1.0]
)
DEBUG 2015-07-14 16:19:55,262 [[resource_bulk_upload].http.requester.AuntBertha_Production(3) SelectorRunner] com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider: RESPONSE: HttpResponsePacket (
  status=404
  reason=Not Found
  protocol=HTTP/1.1
  content-length=-1
  committed=false
  headers=[
      cache-control=no-cache, no-store, max-age=0, must-revalidate
      pragma=no-cache
      expires=Fri, 01 Jan 1990 00:00:00 GMT
      date=Tue, 14 Jul 2015 21:19:49 GMT
      vary=X-Origin
      content-type=text/html; charset=UTF-8
      x-content-type-options=nosniff
      x-frame-options=SAMEORIGIN
      x-xss-protection=1; mode=block
      server=GSE
      alternate-protocol=443:quic,p=1
      accept-ranges=none
      transfer-encoding=chunked]
)

如果我将请求更改为ping例如google.com却可以正常工作.我在这里想念什么?我的工作curl和损坏的<flow>之间不匹配是什么?

If I change the request to ping e.g. google.com instead, it works as expected. What am I missing here? What's the mismatch between my working curl and broken <flow>?

推荐答案

404未找到意味着它确实连接到某个地方并获得了404响应.

404 not found means it did connect somewhere and got a 404 response back.

从网络角度来看，您的通话实际上是成功的.

So your call is actually successful from a network perspective.

因此代码基本上可以正常工作.可能是David提出了Header问题，例如user-agent错误或IP/域调用错误，或者执行请求的Mule节点具有一些自定义代理配置或类似属性.但是您不确定代码不起作用"的声明，我不确定代码是否真正起作用，似乎配置是行不通的.

So the code basically works. It could be either like David suggested a Header issue, like user-agent is wrong or the IP/domain calling is wrong, or the Mule node executing the request has some custom proxy configuration or similar. But your statement of "code does not work", I am not sure, the code actually works, it seems the configuration is what does not work.

这篇关于使用Mule 3.6 HTTP Connector的意外404的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！