mojo/public/interfaces/service_provider/content_handler.mojom - Issue 423963004: First cut at "content handling" support in Mojo.

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: mojo/public/interfaces/service_provider/content_handler.mojom

Issue 423963004: First cut at "content handling" support in Mojo. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Create a dedicated demo app instead of using wget Created 6 years, 4 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

OLD	NEW
(Empty)
	1 // Copyright 2014 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 import "mojo/public/interfaces/service_provider/service_provider.mojom"

	6

	7 module mojo {

	8

	9 interface ContentHandler {

	10 OnConnect(string url,

	11 handle<data_pipe_consumer> content,
	darin (slow to review) 2014/08/03 06:12:02 Are you thinking we can get away with not supplyin Are you thinking we can get away with not supplying the URLResponse here? Some response headers (e.g., Content-Type) will matter to content handlers. An app might be registered as a content handler for N mime types. It might also find the charset hint from the response headers useful. But, perhaps it is possible to provide something less than a full URLResponse data structure here. Also, is it useful / good (from a security perspective) to provide the chain of redirects to the content handler? Aaron Boodman 2014/08/03 11:11:40 No, we will need the full URLResponse or something Show quoted text On 2014/08/03 06:12:02, darin wrote: > Are you thinking we can get away with not supplying the URLResponse here? Some > response headers (e.g., Content-Type) will matter to content handlers. An app > might be registered as a content handler for N mime types. It might also find > the charset hint from the response headers useful. But, perhaps it is possible > to provide something less than a full URLResponse data structure here. No, we will need the full URLResponse or something close to it. I encountered some dependency issues using it, changed it to this data pipe temporarily, then forgot to go back and figure that out. I will look at it again, maybe in a separate change. Show quoted text > Also, is it useful / good (from a security perspective) to provide the chain of > redirects to the content handler? I'm not sure. Currently I don't see anything in URLResponse that exposes the redirect chain - am I missing it? Does Blink need the redirect chain for any reason?
	12 ServiceProvider service_provider);

	13 };

	14

	15 }

OLD	NEW

« no previous file with comments | « mojo/mojo_public.gypi ('k') | mojo/service_manager/background_service_loader.h » ('j') | no next file with comments »