Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: migrate protocol module to NetworkService (Part 4) #18084

Merged
merged 12 commits into from May 3, 2019

Conversation

Projects
None yet
2 participants
@zcbenz
Copy link
Member

commented May 1, 2019

Description of Change

Refs #15791.

This is part of the changes to reimplement the protocol module with NetworkService API, the new implementation lives in parallel with current implementation and only gets used when --enable-features=NetworkService is passed.

This PR implements the protocol.registerStreamProtocol with NetworkService APIs, and also refactors the code of AtomURLLoaderFactory.

Due to the migration of NetworkService APIs, it is now possible to return different types of responses in one protocol handler, I have added an experimental protocol.registerProtocol API to demonstrate the possibility:

protocol.registerProtocol('test', (request, callback) => {
  if (/* stream */) {
    callback('stream', {
      statusCode: 200,
      headers: {
        'content-type': 'text/html'
      },
      data: createStream('<h5>Response</h5>')
    })
  } else if (/* file */) {
    callback('file', '/path/to/file')
  }
})

Checklist

Release Notes

Notes: no-notes

return;
}

new NodeStreamLoader(std::move(head), std::move(client), data.isolate(),

This comment has been minimized.

Copy link
@deepak1556

deepak1556 May 1, 2019

Member

Is it okay for this class to manage its own lifetime ?

This comment has been minimized.

Copy link
@zcbenz

zcbenz May 2, 2019

Author Member

This seems to be the only choice, I couldn't find a way to have Chromium manage its lifetime. content::FileURLLoader is also managing its own lifetime:

https://cs.chromium.org/chromium/src/content/browser/file_url_loader_factory.cc?type=cs&g=0&l=341

This comment has been minimized.

Copy link
@deepak1556

deepak1556 May 2, 2019

Member

Oh cool, in that case should we check if producer_ and client_ handles are bound before accessing the methods when we receive data from JS land ?

This comment has been minimized.

Copy link
@zcbenz

zcbenz May 2, 2019

Author Member

content::FileURLLoader does not check bound for every call but it deletes itself when connection error happens, I have added the same for NodeStreamLoader.

@electron-cation electron-cation bot removed the new-pr 🌱 label May 2, 2019

@zcbenz zcbenz force-pushed the ns-protocol-stream branch from 3066e28 to 3fbc68e May 2, 2019

@zcbenz zcbenz merged commit 0a6eb8a into master May 3, 2019

6 checks passed

Semantic Pull Request ready to be squashed
Details
appveyor: win-ia32-testing AppVeyor build succeeded
Details
appveyor: win-ia32-testing-pr AppVeyor build succeeded
Details
appveyor: win-x64-testing AppVeyor build succeeded
Details
appveyor: win-x64-testing-pr AppVeyor build succeeded
Details
release-notes Release notes found
@release-clerk

This comment has been minimized.

Copy link

commented May 3, 2019

No Release Notes

@zcbenz zcbenz deleted the ns-protocol-stream branch May 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.