Firebase-functions: Deployed functions req.method not correct for HEAD requests

[inorganik]

Version info

firebase-functions: 2.0.3

firebase-tools: 6.1.1

firebase-admin: 6.0.0

node engine: bug appeared in 6 and 8
express: 4.16.3

Test case

Making a head request with curl -I to an express route, while serving locally the req.method is 'HEAD'. Once deployed however, it is 'GET'. This is an issue, because I am tracking downloaded files and I don't want to count head requests which do not download the file.

Steps to reproduce

index.ts:

const echoMethod = (req, res) => {
  const request = {
    method: req.method,
    path: req.path
  }
  return admin.firestore().collection('reqTest').add(request).then(() =>
    res.sendStatus(200);
  ).catch(err => 
    res.sendStatus(500);
  );
}

const testApp = express();
testApp.all('/all', echoMethod);
// have also tried testApp.head(), but same result

const app = express();
app.use('/api', testApp);
export const test = functions.https.onRequest(app);

Then send curl request:
curl -I https://myfirebaseapp.com/api/all

Were you able to successfully deploy your functions?

No errors, deploy successful

Expected behavior

req.method should be 'HEAD' for head requests. When served locally, this works properly. After deployment, it is recorded as 'GET'.

Actual behavior

req.method for head request is recorded as 'GET'.

[inorganik]

Guessing this is due to the nginx proxy. I am getting proper head responses, but how can I detect this in the cloud function? I really need to detect head requests... Perhaps you could add a header?

x-request-method: HEAD

This has really blocked me, I'd really appreciate someone looking into this. Thanks.

[kevinajian]

Hi @inorganik,

Thanks for your feedback. Currently HEAD is not supported as you noted, and as listed in the docs.

We are tracking this issue internally (reference 120678423).

[inorganik]

Thanks Kevin... what about a custom header in the meantime? x-request-method? Is there any other way to detect HEAD requests?

[kevinajian]

Custom headers should work. After you set it you should be able to get the value with req.get('x-request-method').

[inorganik]

Sorry I think you misunderstood, I’m not making the requests... I don’t
have control over the headers. I was suggesting that nginx set a custom
header because it is passing a HEAD to the function as a GET.

On Fri, Dec 7, 2018 at 5:36 PM Kevin Jian [e-mail] wrote:

Custom headers should work. After you set it you should be able to get the
value with req.get('x-request-method').

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-functions/issues/351#issuecomment-445412541,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGr8Z2R8zNPolRmW__wPcToTaIEU0-Aks5u2wmjgaJpZM4ZE3-u
.

>

Sent from Gmail Mobile

[inorganik]

Thanks to Joel in Firebase support, I discovered that this issue is caused by the hosting rewrite I was using, because I wanted to have the endpoint under my own domain.

If I make the request directly to function (under cloudfunctions.net), without the rewrite, I am able to detect the HEAD. request. So it turns out it is the rewrite that is hiding the request method.

Please keep this issue open though - I believe rewrites should support HEAD requests - I would rather expose the endpoint under my own domain instead of the cloud functions domain.

[kevinajian]

Thanks for the update. I'll keep this open.

[thechenky]

Hi @inorganik thanks for the feature request. We are trying not to keep Github issues open if we're not actively working on them and they are not actual bugs. However, we hear you that this support should exist. I have filed an internal ticket for this request, reference bug 121049520. I'm going to close this out meanwhile.

[inorganik]

Hi @thechenky and @kevinajian I'm just wondering if there has been any movement on this issue. It is preventing me from using a custom domain (I have to use "https://us-central1-....") so that I can track HEAD requests.

• Kevin tracked it as bug 120678423
• Diana tracked it as bug 121049520

Thanks.

[thechenky]

Hi @inorganik, this requires some discussion with our partner teams, let me check on that for you. Will post back with any updates.

[thechenky]

The correct internal tracking bug is 120678423 as 121049520 has been marked duplicate. There has been no activity on that bug so looks like it's not prioritized. I pinged the bug again to ask if there are plans to implement. Will post back with any updates I get. Thanks!

[inorganik]

Thanks @thechenky I appreciate it!