Proposal: we add new bugzilla component for webRTC stuff?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: we add new bugzilla component for webRTC stuff?

Jason Duell-3
I see Randell is adding bugs for WebRTC and filing them under "network".
I suggest we create a 'WebRTC' (or whatever) bugzilla component to put
these under. From past experience it gets harder to create such a bin as
time goes by (it's a lot of email traffic and tedious to reclassify
everything). And the WebRTC work is different enough from the rest of
our networking that people may want to follow it but not get all the
other networking bug traffic.

Jason
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Brian Smith-31
+1. And, please add a new component for the UA string too.
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Julian Reschke
On 2012-02-22 22:04, Brian Smith wrote:
> +1. And, please add a new component for the UA string too.
> ...

I almost read this as "*to* the UA string" :-)
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Jason Duell-3
In reply to this post by Brian Smith-31
On 02/22/2012 01:04 PM, Brian Smith wrote:
> +1. And, please add a new component for the UA string too.

No way!  Nothing about the UA string can be changed in case we break web
compat.  Not even its bugzilla component!

Added bug 729710 for the webRTC component(s).

Jason

_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Gervase Markham
In reply to this post by Jason Duell-3
On 22/02/12 21:04, Brian Smith wrote:
> +1. And, please add a new component for the UA string too.

I recently proposed a new Module to the module-owners group for "HTTP
Headers", including the UA string, Accept etc. Let's wait and see what
comes of that proposal; if it's accepted, it might be best to create a
Bugzilla component to match.

Gerv
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Christian Biesinger-2
On Thu, Feb 23, 2012 at 10:46 AM, Gervase Markham <[hidden email]> wrote:
> On 22/02/12 21:04, Brian Smith wrote:
>>
>> +1. And, please add a new component for the UA string too.
>
>
> I recently proposed a new Module to the module-owners group for "HTTP
> Headers", including the UA string, Accept etc. Let's wait and see what comes
> of that proposal; if it's accepted, it might be best to create a Bugzilla
> component to match.

Stupid question time: What is the "module owners group"? It seems like
something I should at least know about :-)

-christian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Gervase Markham
In reply to this post by Gervase Markham
On 23/02/12 18:51, Christian Biesinger wrote:
> Stupid question time: What is the "module owners group"? It seems like
> something I should at least know about :-)

https://wiki.mozilla.org/Modules/Activities#Module_Ownership_System

Gerv


_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Brian Smith-31
In reply to this post by Gervase Markham
Gervase Markham wrote:
> On 22/02/12 21:04, Brian Smith wrote:
> > +1. And, please add a new component for the UA string too.
>
> I recently proposed a new Module to the module-owners group for "HTTP
> Headers", including the UA string, Accept etc. Let's wait and see
> what comes of that proposal; if it's accepted, it might be best to
> create a Bugzilla component to match.

I don't think "HTTP Headers" is a good module to have. Content team (for Accept-*) or Necko team (everything else except User-Agent) is the one that should "own" most of the other headers, and to make it simple, we might as well keep them in Necko. User-Agent is the only header that Necko team would say good riddance to, AFAICT.

Cheers,
Brian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Henri Sivonen
On Mon, Feb 27, 2012 at 7:57 AM, Brian Smith <[hidden email]> wrote:
> User-Agent is the only header that Necko team would say good riddance to, AFAICT.

I think it would make sense to carefully police additions to HTTP
headers beyond User-Agent. (Also removals, I guess, from the site
compat perspective.) Proposals to add stuff pop up from time to time
and they tend to flop with the request left bloated. (Notable
exception: Accept-Encoding: gzip. DNT: 1 seems to be off to a good
start, too, but it's too early to tell what happens to it on the long
term.)

One failure that added bloat that I'm partially guilty for is the
Accept header. Wouldn't you say good riddance to Accept if we could as
far as site compat goes?

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Gervase Markham
In reply to this post by Brian Smith-31
On 27/02/12 09:41, Henri Sivonen wrote:

> I think it would make sense to carefully police additions to HTTP
> headers beyond User-Agent. (Also removals, I guess, from the site
> compat perspective.) Proposals to add stuff pop up from time to time
> and they tend to flop with the request left bloated. (Notable
> exception: Accept-Encoding: gzip. DNT: 1 seems to be off to a good
> start, too, but it's too early to tell what happens to it on the long
> term.)
>
> One failure that added bloat that I'm partially guilty for is the
> Accept header. Wouldn't you say good riddance to Accept if we could as
> far as site compat goes?

Accept: is certainly on my personal hit-list, and was my other example
of a header which excites controversy. (Or, at least, it has in the past
- it might not do so today.) I would work on eliminating Accept by
first, issuing a wide call (via hacks blog and other places) for
existing examples of people using content-negotiation via Accept. If, as
I would suspect, there are few or none, we can look at eliminating it by
doing some web scraping and seeing if it makes a difference, like we
have done with User-Agent:.

Gerv

_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Julian Reschke
On 2012-02-27 11:32, Gervase Markham wrote:

> On 27/02/12 09:41, Henri Sivonen wrote:
>> I think it would make sense to carefully police additions to HTTP
>> headers beyond User-Agent. (Also removals, I guess, from the site
>> compat perspective.) Proposals to add stuff pop up from time to time
>> and they tend to flop with the request left bloated. (Notable
>> exception: Accept-Encoding: gzip. DNT: 1 seems to be off to a good
>> start, too, but it's too early to tell what happens to it on the long
>> term.)
>>
>> One failure that added bloat that I'm partially guilty for is the
>> Accept header. Wouldn't you say good riddance to Accept if we could as
>> far as site compat goes?
>
> Accept: is certainly on my personal hit-list, and was my other example
> of a header which excites controversy. (Or, at least, it has in the past
> - it might not do so today.) I would work on eliminating Accept by
> first, issuing a wide call (via hacks blog and other places) for
> existing examples of people using content-negotiation via Accept. If, as
> I would suspect, there are few or none, we can look at eliminating it by
> doing some web scraping and seeing if it makes a difference, like we
> have done with User-Agent:.

The problem IMHO isn't content negotiation per se (for instance, in
Ajax), but web servers that fail if Accept is absent.

Best regards, Julian

_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Gervase Markham
In reply to this post by Gervase Markham
On 27/02/12 11:10, Julian Reschke wrote:
> The problem IMHO isn't content negotiation per se (for instance, in
> Ajax), but web servers that fail if Accept is absent.

This is what we'd test. If it was too disruptive, we'd go to "Accept:
*/*" (which I believe is what IE sends).

Gerv
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: we add new bugzilla component for webRTC stuff?

Patrick McManus
In reply to this post by Brian Smith-31
The logical distinction is transport headers vs content headers. I think
the network owner and peers should decide issues related to transport
(Connection headers, cache headers, transfer headers, delimiter related
headers, etc..) but someone closer to Firefox / Thunderbird / etc should
set those for U-A, Content, etc.. (perhaps differently from other products).

On 2/26/2012 9:57 PM, Brian Smith wrote:
>
> I don't think "HTTP Headers" is a good module to have. Content team (for Accept-*) or Necko team (everything else except User-Agent) is the one that should "own" most of the other headers, and to make it simple, we might as well keep them in Necko. User-Agent is the only header that Necko team would say good riddance to, AFAICT.
>
> Cheers,
> Brian
> _______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network

_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Separate module for User-Agent header (was Re: Proposal: we add new bugzilla component for webRTC stuff?)

Brian Smith-31
In reply to this post by Henri Sivonen
Henri Sivonen wrote:
> One failure that added bloat that I'm partially guilty for is the
> Accept header. Wouldn't you say good riddance to Accept if we could
> as far as site compat goes?

I meant that it would be great to have U-A in a module that people didn't see Necko team as being responsible for, because of the flamewars around it. Accept-* is relatively drama-free.

However, perhaps we still need to closely track changes to User-Agent. In particular, do we need to do anything w.r.t. invalidating entries in the cache when User-Agent and/or other request headers change? I hope that we don't store all these request headers in each cache entry. But, if we don't, then we need to automatically invalidate entries that vary depending on these headers every time they change. (And we need to assume an implicit "Vary: User-Agent" on every cached response, considering how often Vary: User-Agent is wrongly omitted.)

- Brian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Separate module for User-Agent header (was Re: Proposal: we add new bugzilla component for webRTC stuff?)

Christian Biesinger-2
On Mon, Feb 27, 2012 at 11:20 AM, Brian Smith <[hidden email]> wrote:
> Henri Sivonen wrote:
>> One failure that added bloat that I'm partially guilty for is the
>> Accept header. Wouldn't you say good riddance to Accept if we could
>> as far as site compat goes?
>
> I meant that it would be great to have U-A in a module that people didn't see Necko team as being responsible for, because of the flamewars around it. Accept-* is relatively drama-free.
>
> However, perhaps we still need to closely track changes to User-Agent. In particular, do we need to do anything w.r.t. invalidating entries in the cache when User-Agent and/or other request headers change? I hope that we don't store all these request headers in each cache entry. But, if we don't, then we need to automatically invalidate entries that vary depending on these headers every time they change. (And we need to assume an implicit "Vary: User-Agent" on every cached response, considering how often Vary: User-Agent is wrongly omitted.)

Yeah, we don't store all request headers. We store a hash of the
cookie header, and we store all headers that were specified in Vary.

-christian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Separate module for User-Agent header (was Re: Proposal: we add new bugzilla component for webRTC stuff?)

Brian Smith-31
Christian Biesinger wrote:
> Brian Smith <[hidden email]> wrote:
> > these headers every time they change. (And we need to assume an
> > implicit "Vary: User-Agent" on every cached response, considering
> > how often Vary: User-Agent is wrongly omitted.)

A literal application of that idea is not realistic because we change U-A for every release. But, this is something to keep in mind if we make any (more) major changes other than version numbers.

> Yeah, we don't store all request headers. We store a hash of the
> cookie header, and we store all headers that were specified in Vary.

Couldn't/shouldn't we store a hash of all the headers that were specified in Vary too, instead of storing their values? Maybe we could even combine it with the cookie hash. This would be more space-efficient.

- Brian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Separate module for User-Agent header (was Re: Proposal: we add new bugzilla component for webRTC stuff?)

Patrick McManus
On Tue, 2012-02-28 at 15:41 -0800, Brian Smith wrote:
> Christian Biesinger wrote:
> > Brian Smith <[hidden email]> wrote:
> > > these headers every time they change. (And we need to assume an
> > > implicit "Vary: User-Agent" on every cached response, considering
> > > how often Vary: User-Agent is wrongly omitted.)
>
> A literal application of that idea is not realistic because we change U-A for every release. But, this is something to keep in mind if we make any (more) major changes other than version numbers.
>

+1 here. we don't need to bust local cache entries that vary on UA. We
know apriori the client didn't change to another browser :) - no need to
be slaves to semantics - that isn't serving the user.


_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|

Re: Separate module for User-Agent header (was Re: Proposal: we add new bugzilla component for webRTC stuff?)

Christian Biesinger-2
In reply to this post by Brian Smith-31
On 2/28/2012 15:41, Brian Smith wrote:
> Christian Biesinger wrote:
>> Yeah, we don't store all request headers. We store a hash of the
>> cookie header, and we store all headers that were specified in Vary.
>
> Couldn't/shouldn't we store a hash of all the headers that were specified in Vary too, instead of storing their values? Maybe we could even combine it with the cookie hash. This would be more space-efficient.


That sounds reasonable. Really the code looks like it does because we
originally we didn't support Vary: Cookie (for privacy reasons) and then
we added support for it using the hashing. Hashing them all together
does sound like a good enhancement.

FYI, the code is at
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#3106
(and also
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#1604)

-christian
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network