Deploying pages

[Ahmad-2213]

For pages deployment, even though i see the "hello world" message , but the link isn't working.
I have also bind a sub domain and the configuration is generated as expected, however , when it comes to be tested on xray-based clients, it fails, whilst the script works flawlessly on workers.

[arkanpay]

Same as here. Deploying on Cloudflare Pages is necessary because, currently, it doesn't have a rate limit.

[vrnobody]

Unfortunately, I agree with #1 . It seems that pages does not support gRPC.

[Ahmad-2213]

Unfortunately, I agree with #1 . It seems that pages does not support gRPC.

hoommm i see!
is grpc header necessary to deploy xhttp?
maybe another mode of this protocol could be implemented?(stream-up?)
if it's not possible, we may try to decrease the number of requests by longer keep alives and use the same connection for other requests.(xmux) (what are the best xmux settings for this objective?)

[vrnobody]

Adding a gRPC header is like exploiting a vulnerability of Cloudflare. Strictly speaking stream-one mode is not regular HTTP POST. As @yomnxkcs has pointed out in issue 443, other xhttp modes will not work.
I am not familiar with xmux settings. Perhaps you can try diffent configuration combinations and share your findings.

[Ahmad-2213]

@RPRX
What do you think on this issue?

[RPRX]

我才看到你们已经把这个搞出来了

我没有研究过 workers 和 pages 的区别，但我看到 response type 是 application/grpc，或许改成 text/event-stream 或没有试试

BTW，response 似乎没有 X-Padding，需要补上 @vrnobody

[vrnobody]

刚刚加了 padding.

pages 和 workers 的网络不一样，上次测试的时候感觉是 upload 的后续数据包进不去 pages 服务器，而不是 pages 的数据包出不来。同时 pages 没有日志功能对调试很不友好，等个有缘人来试这个吧。

[Ahmad-2213]

You can access logs for pages following this path:
Deployments Tab >> Under Production/All Deployments section , Select View Details >>
Functions

here you can scroll down to find Real-time Logs and begin log stream.

@vrnobody

[Ahmad-2213]

Here is a demonstration of logs:

[vrnobody]

You can access logs for pages following this path: Deployments Tab >> Under Production/All Deployments section , Select View Details >> Functions

here you can scroll down to find Real-time Logs and begin log stream.

@vrnobody

Thanks for the tips. I just tried to deploy xhttp on pages again. I had tested server-send-event header, chunked encoding, padding. Sadly all those tricks don't work.

[Ahmad-2213]

You can access logs for pages following this path: Deployments Tab >> Under Production/All Deployments section , Select View Details >> Functions
here you can scroll down to find Real-time Logs and begin log stream.
@vrnobody

Thanks for the tips. I just tried to deploy xhttp on pages again. I had tested server-send-event header, chunked encoding, padding. Sadly all those tricks don't work.

But it seems that requests are caught by the server because logs confirm this claim.
So the problem might be lying on Server-send-headers which cause this issue to happen.
I suspect that if we could try to simulate the WS method for sending data, it'll work probably?!
However you mentioned that you've tried various header types.

[vrnobody]

There is a slight difference between stream-one mode and regular HTTP POST. Stream-one mod needs to send multiple upload packets separately with in one request. From the logs I observed, only the first packet makes it way into the pages server, other packets are dropped or something else. I still think the problem lies on the upload side. Those tricks only work on the download side. I'm out of ideas.

[gtnttot]

看到这个项目可以直接在cf workers上部署xhttp，不知能帮改一个支持xhttp的workers 反代代码吗？我按之前的写法，反代搭建了xhttp的vps，只能过packet-up，过不了stream-up。

export default {
  async fetch(request, env) {
    let url = new URL(request.url);
    if (url.pathname.startsWith('/')) {
      url.hostname = 'example.com'
      let new_request = new Request(url, request);
      return fetch(new_request);
    }
    return env.ASSETS.fetch(request);
  },
};

[Ahmad-2213]

There is a slight difference between stream-one mode and regular HTTP POST. Stream-one mod needs to send multiple upload packets separately with in one request. From the logs I observed, only the first packet makes it way into the pages server, other packets are dropped or something else. I still think the problem lies on the upload side. Those tricks only work on the download side. I'm out of ideas.

@RPRX what do you think?